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I .   INTRODDCT ION 

A.  BACKGROUND 

An  Inteffrated  Circuit  (IC)  is  a  small  silicon 
semiconductor  crystal  containing  electrical  components  sucn 
as  transistors,  diodes,  resistors,  capacitors,  or 
interconnected  digital  gates.  As  tne  technology  of  IC's  nas 
improved,  tne  number  of  components  tnat  can  be  put  on  a 
single  silicon  chip  aas  increased.  If  a  pacicage  contains 
several  logic  gates  it  is  considered  to  be  a  small-scale 
Inteeeration  (SSI)  device.  Medium-scale  inte^eration  (MSI) 
devices  contain  10  to  100  gates  and  perform  a  complete  logic 
function.  Large-scale  intecrration  (LSI)  devices  perform 
loeic  functions  with  over  100  devices  and  very-laree-scale 
integration  (VLSI)  units  contain  thousands  of  gates  in  a 
single  chip.  The  INTEL  iAPX  432  contains  160,000  transistors 
on  two  Chips  and  is  considered  a  VLSI  device. 

B.  THSSIS  DESCRIPTION 

The  Intel  432/670  system  is  a  commercial  product  that 
uses  the  iAPX  432  microprocessor.  Incorporating  many  new 
architectural  features,  with  the  goal  to  significantly 
reduce  the  software  cost,  tne  Intel  432  has  been  neraiaea  as 
"the  most  significant  architectural  development  in  tne  last 
5-10  years"  [Ref.  Ij ,  In  addition  to  tne  VLSI  tecnnology, 
the   432   contains   architectural   advances   that    enable 
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implementation   of   transparent  multiprocessing   and   a 
protected  computing  and  communications  environment. 

The  purpose  of  this  thesis  is  to  continue  a  series  of 
benchmarlc  performance  tests  on  the  Intel  432  that  have  been 
reported  in  Shoop  [Ref .  2J  and  Applegate  [Ref  3J  .  The  goal 
of  these  tests  is  to  determine  if  the  432/670  system  is 
capable  of  sustaining  incremental  performance  improvements 
as  processors  are  added  to  the  system. 

C.   THESIS  ORSANIZATON 

This  thesis  is  composed  of  three  major  sections.  Chapter 
II  presents  a  brief  history  of  computer  architecture 
development  from  the  first  electronic  computers  to  tne 
object  oriented  architectures.  Chapter  III  provides  a 
systematic  description  of  the  Intel  432/670  system  while 
Chapter  IV  provides  the  actual  Bencnmaric  performance 
evaluations  of  the  Intel  432/670  system  in  tae 
multiprocessor/multi process  environment. 
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II.   HISTORICAL  DE7EIiQP!:iENT 

Since  computer  systems  architecture  is  not  restriciea  to 
the  sole  aspect  of  nardtfare,  it  is  not  easily  defined. 
Junctional  boxes  and  their  complexity,  tne  interconnection 
between  tne  boxes,  switcnes,  controllers,  tne  way  messages 
are  passed  and  received,  and  tne  blend  of  hardware  and 
software  features  must  be  considered  in  tne  cveraii 
architectural  structure.  The  Intel  432  architecture  is  the 
result  of  an  evolutionary  development  in  computer  systems. 
It  incorporates  many  advanced  features  which  nave  evolved 
throughout  the  history  of  computers.  Accordingly,  to 
establish  the  proper  perspective  of  the  concepts  of  tne 
Intel  432  a  brief  history  of  computer  architecture 
development  is  presented. 

One  of  the  earlier  electronic  computers  was  completed  in 
1946  at  tne  University  of  Pennsylvania  Moore  School  of 
Bnffineerihff.  ENIAC,  capable  of  performing  nearly  bi?ee 
additions  or  subtractions  per  second,  consisted  of  more  than 
lB00fe5  vacuum  tubes  and  1500  relays  and  was  used  to  compute 
ballistic  trajectories.  Wired  for  specific  computations,  any 
modifications  or  program  replacements  on  SNIAC  required  new 
wiring  and  its  associated  excessive  set  up  time.  In  an 
effort  to  eliminate  the  setup  time,  von  Neumann  and  others, 
consulting  at  tne  Moore  Scnool  of  Engineering,   designed  tae 
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first  stored  program  computer.  However,  tne  first 
operational  stored  proeram  computer  (EDSAC)  was  tuilt  ai 
Cambridge,  England  in  1949.  In  addition  to  being  tne  first 
computer  to  execute  stored  programs*  EDSAC  introduced  tne 
notion  of  memory  tiierarchy  t&rougb  the  primary  memory  and 
bacKing  drum. 

Meanwhile,  von  Neumann  continued  bis  researcn  at  the 
Institute  for  Advanced  Studies  (IAS)  at  Princeton  wnere  ne 
developed  tne  von  Neumann  architecture  which  is  in  wide  use 
today.  The  von  Neumann  architecture  is  considered  to  be 
based  on  four  tcey  concepts: 


1.  A  single,  sequentially  addressed  memory.  A 
program  and  its  data  are  stored  in  a  single 
memory,  and  the  memory  is  referenced  with 
sequential  addresses. 

2.  A  linear  memory.  Tne  memory  is  one 
dimensional,  or  has  tne  appearance  of  vector 
of  words. 

3.  No  explicit  distinctions  between  instructions 
and  data.  Instructions  and  data  are 
distinquisned  implicitly  by  tne  operations 
directed  toward  tnem. 


4.   Meaning   is 
[Ref.  4J 


not 


an   inherent   part 


of 


data  . 


The  early  programming  styles  supported  single  user,  non- 
subroutine  environments  that  employed  a  looping  technique  by 
modifying  instructions.  Since  instruction  modification 
generated  only  serially  reuseable  code,  mul tipro^ramminff  was 
not   feasible   and  index  registers  were  developed   at   tne 
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University  of  ^ancnester   to   maKe   it   possible   to   call 
subroutines,  pass  parameters,  and  generate  reentrant  code. 

UNIVAC  I,  built  for  tne  Ijureau  of  Census,  nad  a  tape 
system  taat  used  error  cneclcing  procedures  and  buffering 
capabilities  to  read  tapes  botn  forward  and  backward.  It  was 
intended  for  both  scientific  and  commercial  appli'^ations  and 
can  be  considered  tne  first  successful  commercial  computer. 
Tne  system  arcnitectur-e  durine  tnis  period  is  characterized 
in  Figure  2.1. 


MEMORY 


CPU 


I/O 


PERIPHERALS 
Figure  2.1  Early  System  Arcnitecture 

As   computer  applications   advanced   into   commercial 
fields,    I/O   intensive   requirements   were   generated. 
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Arcnitecture  Improvements  to  ennance  computational  speeds 
and  enable  overlap  to  permit  interleaved  I/O  and 
computational  operations  were  developed.  Pipelining,  a 
tectinique  used  to  speed  computer  operations  by  multiplexing 
memory  accesses  .pa  with  instruction  decoding  and  execution, 
is  one  example  of  enhancement. 

Systems  became  faster,  smaller,  and  more  reliable 
throuffhout  the  1960's  as  transistors  and  integrated  circuits 
allowed  the  building  of  more  general  purpose  registers  and 
regular  architectures.  Figures  2.2,  2.3,  and  2.4  depict  tne 
architectures  of  this  period. 


CPU 


I/O 


PERIPHERALS 
Figure  2.2  Dual  Port  Memory  Architecture 

Figure  2,2,  representing  a  dual  port  memory 
arcnitecture,  provides  a  faster  access  path  but  demands 
extra  hardware  in  the  memory  which  performs  independent   I/O 
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operations.  The  I/O  dus  structure,  Figure  2.3,  connects  tne 
I/O  devices  to  memory  tnrougn  device  controllers  tnat  are, 
in  many  cases,  mini-computers.  It  still  requires  a  resource 
manager  or  a  distributed  control  discipline.  Tne  central 
system  controller  shown  in  Fisrure  2.4  is  cased  around  a 
giant  switch  which  controls  multiple  processors  and  memory 
units  in  a  modular  fashion. 


DSVICE 
CONTROLLER 


^Er^ORY 


DE7ICE 


I   CONTROLLER   I 


DEVICE 
CONTROLLER 


Figure  2.3   I/O  Bus  Architecture 

As  hardware  cost  decreased,  desi.?ners  eliminated  the 
complicated  central  I/O  control  in  favor  of  a  ous  oriented 
structure  (Figrure  2.5K  It  is  flexible,  modular,  and 
conceptually  simple  and  most  architectures  today  contain 
variations  of  this  bus  oriented  structure.  S-10fe),  MULTIBUS, 
EXORBUS ,  and  VMEbus  are  a  few  bus  oriented  architectures  on 
the  current  mariret. 
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I     MEMORY     I      j     MEMORY     |      !      CPU        | 
I  II  It  I 

I  II  II  .1 


\      / 

\       !        / 
\   / 

—  j  control!  — 

— !   UNIT   !  — 

/      \ 

/       !        \ 

I     I/O        !      [COMMUNICATION  i       !       CPU       j 
I   PROCESSOR    !      I   PROCESSOR    !       !  1 


Figure  2.4   Central  System  Controller 

A.5  fast  processors  were  developed,  efforts  to  feeep  tfte 
processors  busy,  wnile  tne  slow  peripnerals  were  reacting  to 
instructions,  culminated  in  mul  tipro^ramminff  and  trie 
associated  tasK  switcning  and  Hardware  memory  protection 
instruction  set  enhancements.  Microprofframmin^,  a  tecftnique 
wtiica  Dreafes  eacn  instruction  into  a  series  of  eleTentary 
steps  was  also  developed  in  the  1960's  to  reduce  tne  cost  of 
the  sophisticated  instruction  sets  by  making  it  easier  to 
develop  a  compatible  series  of  computers  that  covered  a  wide 
ran?e  of  performance. 

Paging  and  segmentation  were  developed  to  support  tne 
concept  of  virtual  memory.  Additionally  cacne  memory,  whirn 
is  fast  memory  physically  close  to  tne  central  processor, 
was  developed  to  improve  CPU  performance.  In  general,  the 
advances  in  meiiory  management  resulted  in  a  five  level 
hierarchy  that  consisted  of  registers,   cache,   main  memory. 
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and   Ciign-speed   dislc    or  drum   for    Daclcin^   store   and      low-speed 
lisff  or   tape   for   long-term  program  storage. 


I  M3?^0RT 


MEMORY 


CPU 


I/O 
PROCESSOR 


i COMMUNICATION     i 
!       PROCESSOR         1 


Figure  2.5 


Single  Bus  Arcnitecure 


CPU 


Multiprocessors,  anotner  concept  introduced  in  tne 
1960'5,  are  cnaracterized  arcnitecturally  by  v»netner  tne 
processors  are  identical,  execute  the  same  instruction 
stream,  or  operate  on  one  or  more  data  streams.  However,  it 
was  tne  Intel  4(^04  microprocessor  wtiicn  was  developed  in 
1971  tnat  was  responsible  for  a  continued  unpresidented 
evolution  in  technology  during  tne  iy70's  which  produced  tne 
inexpensive  processors  and  encouraged  tne  use  of 
multiprocesssing.  Specialized  database  processors  and 
arithmetic  processors  are  a  few  examples  of  expansion  in 
this  area. 

As  complexity  in  microcomputer  systems  increased  with 
decreasing  nardware  cost,  software  systems  were  expanding  to 
lae.5     advantage  of  the  new  capaolities.   Software   engineers 
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soon  discovered  tnat  large  software  systems  were  among  tne 
most  difficult  enffineerin?  projects.  Tne  use  of  subroutines, 
bloct  structured  languages,  procedures,  functions,  stepwise 
refinement  and  structured  programmine  were  tecnniques 
developed  to  assist  in  solving  tne  software  engineering 
problems.  Ea ta  abstraction,  employing  tne  concepts  of 
encapsulation  of  data  structures,  uniform  procedure/message 
interface,  and  decomposition  of  design,  was  a  furtner 
extension  of  the  effort  to  produce  reliable  software. 
Wnile  tnese  software  concepts  were  being  developed, 
evolution  in  nardware  protection  structures  can  be  observea 
in  "supervisor  vs.  user  state  in  tne  IBM  360  systems, 
nierarcnical  rings  in  Multics,  and  multiple  domains  in  tne 
Plessy  s/252,  CAL/TSS,  Hydra,  and  CAP.  Key  concepts  of  tnese 
domain  based  systems  include  independent  address  spaces, 
capability-based  addressing  and  access  control,  and  tne 
decomposition  of  tne  operating  system  into  a  useful  set  of 
abstractions."  [Ref.  5j  Additionally  descriptors  and  ac?ess 
control  concepts  were  introduced  to  proviie  protection  by 
establisnin?  a  reouirement  for  autnorization  to  access  data 
elements . 

A  major  departure  from  one  of  tne  4ey  concepts  of  the 
von  Neumann  architecture  is  observed  in  tagged  storage.  All 
information  witnin  storage  is  self-identifying.  Based  on  tne 
information  contained  in  the  tag  field,  tne  macnine 
instructions   can  determine  tne  semantics  of  eacn   operation 
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as  well  as  xne  data  conversion  rules  lo  employ.  rfitn  me 
tag  field  you  nave  a  strongly  typed  environment'  tnat 
prohibits  operation  on  improper  data  types  and  permits  tfte 
deferment  of  binding  instructions  to  data  attributes  until 
tbe  time  of  execution. 

As  we  examined  tne  nistory  of  computer  development,  we 
saw  tftat  tbe  early  macbines  used  simple  hardware  operations 
sucn  as  "move  byte"  and  "add  integer"  wnicb  manipulated 
barlward-recoenized   data  types  sucn  as  bytes  and   integers. 

As  tecnnolo^y  progressed  and  computer  hardware  rained 
functionality*  iiore  complicated  operations  sucn  as  floating 
point  were  moved  into  hardware,  which  substantially 
increases  tne  speed  of  tnese  operations.  Enhancement  of 
standard  programming  methods  as  well  as  guaranteed 
enforcement  of  data  protection  were  additional  Benefits 
derived  from  moving  software  functions  into  hardware. 

Recognizing  that  continued  advancements  in  architectural 
enhancement  would  result  in  more  data  structures  being  moved 
into  hardware,  designers  developed  a  methodology  for  viewing 
these  abstractions  that  would  contribute  to  tne  concept  of 
raising  the  level  of  hardware/software  interface.  One  such 
methodology  tnat  integrates  data  abstraction,  domain  based 
protection,  and  nigh  level  system  functionality  is  tne 
object  oriented  methodology. 

The  concept  of  using  objects  can  be  observed,  as  long 
ago  as  1960,   in  LISP,   where  atoms  have  properties  that  can 
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be  related  to  real  world  objects.  SIMULA,  an  extension  of 
AL50L  intended  for  simulation,  included  tbe  ilea  of 
internally  represented  objects  as  instances  of  classes.  In 
an  effort  to  produce  a  profframminff  vehicle  tiiat  would  reduce 
tne  man-macnine  semantic  gap,  Alan  Kay,  wnile  still  a 
graduate  student  at  tne  University  of  Utan,  investigated 
simulation  and  graphics  oriented  programming  languages. 
Taxing  many  of  his  ideas,  sucn  as  classes  and  objects,  from 
SIMULA,  Kay  helped  design  the  language  FLEX.  Continued 
refinement  of  FLEX  carried  tne  object  oriented  paradigm  to  a 
smoother  model  by  incorporating  ideas  from  LOGO,  a  language 
designed  to  teacn  programming  concepts  to  children,  and 
resulted  in  the  Smalltalk  profframmin?  system. 

An  object  is  an  abstraction  that  is  usually  considered 
to  have  the  following  characteristics: 

1.  objects  are  temporal;  they  exist  in  time; 

2.  objects  are  mutable  (subject  to  change),   and  have  a 
state; 

3.  Objects  can  be  created  and  destroyed; 

4.  objects   are   particular   (distinct),    and   can   be 
Shared.    [5ef.  6 J 

In  general  objects  are  similar  to  pacta,ees  in  that  an  object 
is  a  data  structure  that  contains  information  in  an 
organized  manner,  including  a  set  of  basic  operations  tnat 
directly  manipulate  the  data  structure.  It  can  be  referenced 
as  one  entity  and  has  a  label  that  tells  its  type. 
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As  Kay  continued  his  concept  development  throuenout  tne 
1970's,  tne  idea  of  using  an  otject  oriented  metnodoiogy  to 
model  complex  real  world  issues  De^an  to  emerge.  IBM  uses 
object  oriented  design  concepts  for  complex  projects.  Grady 
Booch,  formally  of  tne  USAF  Academy,  advocates  an  object 
oriented  design  using  Ada  to  enforce  a  clear  design 
structure.  Just  as  Smalltalk  nad  used  objects  to  represent  a 
desired  level  of  abstraction,  object-based  arcnitecture  was 
selected  to  model  the  ^rowin^  hardware  complexities. 

Based  on  an  integrated  approach  to  data  abstraction  and 
domain-based  protection,  object  oriented  architecture 
includes  a  form  of  capability  based  addressing  and  supports 
hiffh  level  system  functions  such  as  memory  management, 
process  management,  and  processor  management.  Because  the 
arcnitecture  is  rooted  in  data  aostraction,  good  software 
design  methodology  is  encouraged  which  will  result  in 
software  systems  tnat  will  be  more  reliable  and  nave  reduced 
software  life  cycle  cost.  Elements  of  object-oriented 
arcnitecture  include: 

1.  Objects  for  system  mana,ffement  and  control. 

2.  Objects  for  program  environments,   flow  of  control, 
and  intercommunication. 

3.  Facilities   for  user  object  extensions  and   system 
object  type  management. 

4.  Object  addressing  and  protection  mechanisms. 

5.  An   instruction  interface.   [Ref.  7J 
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System  •nanagement  objects  include  processor  oBjecis, 
process  objects  and  resource  objects.  While  a  processor 
otject  is  a  memory  based  data  structure,  process  objects 
represent  a  unit  of  computational  wort  for  tne  processor  and 
contain  information  regarding  scheduling  and  dispatching. 
Various  resource  objects  are  queue-lite  structures  used  to 
bind  physical  processors  with  ready-to-run  processes.  By 
representing  all  resources  as  objects,  a  uniform  interface 
for  all  system  functions  is  obtained. 

Environment  and  control  objects  include  data  objects, 
instruction  objects,  domain  objects,  context  objects  and 
control  linJc  objects,  while  communication  objects  consist  of 
message  and  port  objects.  Port  objects  are  asynchronous 
communication  pathways  between  processes  and  provide  for  the 
queueing  of  waiting  messages  as  well  as  resolution  of  speed 
disparity  between  concurrent  activities  in  the  system.  An 
ohject  oriented  architecture  with  a  built  in  software 
methodology  should  include  support  for  representing  typing, 
type  manager  packaging,  and  object  authentication  and 
creation.  Object  addressing  and  protection  mechanisms  are 
required  to  support  references,  mapping  and  protection. 
Finally,  the  object  oriented  instruction  interface  provides 
a  uniform  interface  with  uniform  referencing  to  all  tne 
object  based  facilities. 

k  system  environment  can  be  viewed  as  a  single  set  of 
objects  which  are  addressable  by  everyone.  Ranging   from  tne 
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primitive  storage  segment  naving  ail  tne  cnaracteristlcs  of 
a  von  Neumann  store,  to  an  abstract  entity  wnose  physical 
form  is  nidden  by  tne  architecture  and  wnose  meaning  is 
defined  solely  by  the  transformations  that  can  be  performed 
on  it,  objects  provide  still  more  protection  by 
encapsulating  data  and  program  modules  in  a  structure  with 
not  only  well  defined  external  visibility  but  carefully 
hidden  internal  structure. 

In  summary,  object  oriented  arcnitectures  were  adapted 
to  model  the  wide  variety  of  hardware  and  software 
constructs  that  have  been  developed  to  enhance  computer 
systems  efficiency  and  reliability.  In  addition  to  raising 
the  level  at  which  the  transition  from  hardware  to  software 
occurs,  object  oriented  architecture  enjoys  technology 
independent  design  through  its  information  hiding  structures 
and  supports  a  variety  of  language  structures  including 
operating  systems  and  reliable  low  life  cycle  cost 
applications  software.  For  these  reasons,  Intel  Corporation 
has  chosen  the  object-oriented  architecture  as  the 
predominant  construct  of  the  iAPX  432. 
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III.   INTEL  432/670  SYSTEM  DESCRIPTION 
AND  COMPONllNT  ARCHITECTURE 


Tnis  chapter  will  present  the  characteristics  and 
advantages  of  the  1APX4:32  over  the  conventional 
microcorrputers .  Additionally,  the  concepts  of  object 
oriented  architecture  will  he  presented  in  a  simplified 
form. 

A.   THE  432  OBJECT  ORIENTED  ARCHITECTURE 

In  an  effort  to  find  a  solution  to  the  software  crisis 
wniie  providing  transparent  multiprocessing,  tne  Intel  432 
designers'  principal  desire  was  to  provide  direct  execution 
time  support  for  hoth  data  abstraction  and  domain-based 
operating  systems.  Recognizing  that  both  of  tne  objectives 
could  he  supported  by  the  object  model,  Intel  selected  the 
object  oriented  architecture  as  tne  principal  design 
construct  to  support  a  software  methodology.  This 
architecture  provides  mechanisms  to  help  the  programmer 
follow  the  object  oriented  methodology, 

1 •   0^i^£i  ^liin ted  Methodo log^ 

Vnat  does  object  oriented  methodology  mean?  One  of 
the  best  ways  to  modularize  programs  is  by  using  the 
principle  of  information  hiding  as  defined  by  D.  L.  Parnas. 
The  basic  idea  is  that  a  module  should  contain  a  collection 
of   related   procedures  and  associated   data   structures   on 
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wnicn  tney  operate.  Procedures  outside  tne  module  should  not 
nave  access  to  the  implementation  details  inside  the  module. 
The  data  can  be  referenced  from  outside  the  module  only  by  a 
call  to  one  of  the  procedures  inside  the  module. 

Modules  that  result  wnen  tnls  principle  is  applied  are 
referred  to  as  abstract  data  types,  extended  types,  or 
Parnas  modules.   Intel   refers   to  tnem   as  type  managers. 

At  the  same  time  that  programming  lan^uasres  research  was 
focusing  on  the  concept  of  a  type  manager  as  the  solution 
to  the  modularization  problem,  operating  system  research  was 
defining  a  very  similar  structure,  the  protection  domain, 
as  the  solution  to  the  security  problem.  Since  operating 
system  personnel  were  concerned  more  with  security  than 
modularization,  they  concentrated  on  the  data  in  these 
domains,  rather  than  the  procedures  which  were  the  focus  of 
the  language  research.  Assigning  the  name  "objects"  to  the 
data  items  associated  with  domains,  operating  systems 
personnel  called  the  whole  information  hiding  methodology 
object   either  tne  oriented  methodology  or  tne  object  model. 

Although  experimental  studies  have  demonstrated  that 
objects  are  superb  models  for  modern  software  systems,  the 
overhead  required  to  maintain  the  model  is  too  excessive  to 
permit  efficient  implementation  without  direct  hardware 
support.  [Ref.  B.J  The  Intel  432  has  hardware  mechanisms 
that  permit  recognition  of  the  following  objects: 
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1.  Processor 

2.  Processes 

3.  Dispatctiins  ports 

4.  Interprocess  messages 

5.  Domains 

5.  Context 

7.  Instruction 

B.  Data 


to  permit  an  effective  management  of  tne  system's 
configuration  and  its  individual  resources  as  weii  as 
support  for  data  abstraction. 

B.   INTEL  432/670  SYSTEM 

Utilizing  tne  advanced  arcnitecture  of  tne  iAPX  432 
Micromainframe  VLSI  computer,  tfte  432  family  presents  a  new 
arcnitecture  in  tne  world  of  microcomputers  wnicn  contains 
the  following'  salient  cftaracteristics . 


1.  Part  of  the  operating  system  is  contained  in  silicon 
and  it  is  called  The  Silicon  OS.  It  supports 
process  scheduling,  interprocess  communication  and 
dynamic  storage  allocation. 

2.  Tne  system  operates  in  botn  single  processor  and 
multiprocessor  configurations  and  it  can  include  up 
to  eignt  (8)  processors,  aithougn  tne  432/670  system 
can  only  support  five  (5)  processors  as  limited  by 
tne  number  of  slots  available  in  tne  motner  board. 
If  one  processor  fails,  the  rest  of  the 
system  can  usually  continue  to  operate. 

3.  Hardware  recognition  of  eight  (8)  data  types. 

4.  Hardware  control  functions  for   16   and   32    bit 
multiply,  divide,  and  remainder  operations. 

5.  Hardwired  control  functions  for  32,  64,  and  80 
bit  floating  point  arithmetic. 

6.  Hardwired  error  correction  and  code  protection. 

7.  Object   oriented  design. 
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9.  Botn  abstract  data  types  and  objects  are  supported 
by  hardware  recognized,  hardware  protected  and 
hardware  manipulated  structures. 

9.  It  has  an  extremely  large  virtual  address  space 
(2**40  bytes)  and  hardware  supplied  mechanisms  for 
impleTienting  virtual  memory  systems  that  can 
exploit  this  address  space. 


The  432/670  system  consists  of  the  three  (3)  subsystems: 


1.  Memory  subsystem.     \  Central  System 

2.  Processor  subsystem.   / 

3.  Peripheral  subsystem. 


and  two  busses: 


1.  System   bus   baclcplane. 

2.  Multibus    bacfcplane. 


Before  analyzing  each  one  the  subsystems,  the  following 
observations  of  the  systems  architecture  are  germane: 

1.  The  whole  memory  is  accessible  by  all  GDPs. 

2.  The  system  is   theoretically  expandable  to   include 
any  number  of  processors  (GDPs). 

3.  6   bit   or   lb  bit  based  systems   can   be   connected 
to   the  system  for  performing  I/O. 

Figure  3.1  Illustrates  the  boundary  between  the  central 
system  and  peripheral  subsystems.  In  addition  to  seperating 
data  processing  from  input/output  processing,  this  boundary 
serves  as  a  protection  barrier.  All  information  in  central 
system  memory  is  shielded  by  432  hardware  against 
unauthorized  accesses  but  the  peripheral  subsystem  may  or 
may  not  provide  protection. 
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Pleure   3.1    General   432/570  System  Orffanization. 


Figure  3.2  Illustrates  a  ftypotnetical  configuration  that 
employs  two  peripheral  subsystems.  The  main  system's 
harlware  is  composed  of  two  GDPs  and  a  common  memory  that  is 
Shared  by  these  processors.  The  main  system's  software  is  a 
collection     of      one    or  more    processes    that     execute     on      the 
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Wften  t&e  salient  characteristics  of  tfte  432  are  viewed 
witti  respect  to  tne  levels  of  arcnitecture  wittjin  a 
computing  system  cited  by  Meyers  [Ref.  9],  it  becomes  clear 
that  functions  have  been  moved  from  both  hi,^n  level 
lanffuase  and  operating  system  to  the  hardware  which  raise 
the  boundary  line  between  hardware  and  software  closer  to 
the  end  user.  Figure  3.3  illustrates  the  hardware-software 
interface. 
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Figure  3.3  Hardware  -  Software  Interface 

Appendix  A  gives  a  comparison  of  tne  iAPX  432 
architecture  and  tne  arcnitecture  of  tne  conventional 
mainframes. 

1  •   Central  System 

Tne  central  system  consists  of  the  memory  and   tne 

processor  subsystems. 

a.   Memory  Subsystem 

The  memory  subsystem  resides  on  the  system   bus 
backplane  and  consists  of: 
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1.  One  memory  controller  (MC)  board. 

2.  One  to  Ten  Storage  Array  (SA)  Doards. 

3.  A  Memory  Interleave  (option). 

(1)  M^moiZ  Controller  B^ard.  Tne  memory 
addressed  by  tne  432  is  organized  in  eignt-bit  bytes.  In 
spite  of  this  Intel  says  that  the  432  is  a  32  bit 
microprocessor  and  that  it  can  perform  32,  64,  and  80  bit 
floating  point  arithmetic  because  with  any  read  request  from 
the  system  processor(s ) ,  an  additional  signal  determines  how 
many  bytes  should  be  addressed.  This  is  called  byte 
addressability.  Thus,  based  on  the  processor(s)  requests  a 
word  can  consist  of  1,  2,  4,  8,  or  10  bytes  and  consequently 
8,  16,  32,  48,  64,  or  80  hits  can  be  addressed. 

(2)  Storage  Arra^.  Board.  Each  Storage  Array 
(SA)  board  contains  256K  9  bit  bytes  of  memory.  A  memory 
controller  can  control  up  to  16  SA's  or  4.096  Megabytes  of 
memory.  However,  in  the  current  432/670  systems. there  are 
only  10  slots  available  for  SA  boards. 

Although  the  432  is  a  32  bit  microprocessor 
the  words  are  organized  in  39  bit  wide  bants.  The  seven  (7) 
additional  bits  contain  Error  Correction  Code  (BCD)  for  each 
32  bit  word.  This  is  controlled  by  logic  existing  on  every 
SA  board  for  e-enerating,  checicinfir  and  storing  this  ECD. 
Finally,  the  SA  boards  are  organized  in  64K  byte  bants  of  32 

bit  words,  four  bytes  per  word. 

(3)  Ihterieave  Ofition.  This  option  can  be 
selected   by   setting   tne  Jumpers  of  the  MC   board   to   tne 
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proper  position.  Tne  interleave  option  is  available  to 
enhance  system  performance.  The  interleave  concept  uses  two 
banks  of  memory  with  alternating  addresses  to  provide  faster 
data  access  by  overlapping  memory  operations.  If  tne 
interleave  option  has  been  selected,  SA  boards  must  be 
installed  in  pairs  to  provide  the  alternate  hanics. 

b.  Processor  Subsystem 

The  processor  subsytem,  which  resides  on  the 
system  bus  backplane  and  consists  of  tne  GDP  and  IP  boards, 
is  discussed  under  component  architecture. 

c.  Peripheral   Subsystem 

The  peripheral  subsystems  are  discussed  in  the 
Basic  I/O  Model  and  Windows  sections. 

C.   COMPONSNfiNT  ARCHITECTURE 

In  this  section,   the  basic  architecture,   of  the  major 
components  of  the  system  (  GDP  and  IP)  are  presented. 

1  •   Architecture 

The  432  GDP  consists  of  two  chips  the  instruction 
decoder/microinstruction  sequencer-43201  and  the  execution 
unit-43202.  Appendix  B  contains  the  pin  description  of  each 
Chip  While  Figures  3.4,  and  3.5  show  the  bloclt  diagrams  of 
the  43201  and  43202  chips  respectively. 

In  general,  the  GDP  is  organized  internally  as  a 
three-sta^e  microprofirram-controlled  pipeline.  The  first 
stage  is  the  instruction  decoder  (ID),   the  microinstruction 


34 


sequencer   (MS)  is  contained  in  tne  second  sta^e   wniie   tne 
tttlrl  stage  nouses  tne  execution  unit. 

The  first  two  stages  of  tne  pipeline  are  pnysically 
located  on  tne  432i51  cnip  (Figure  3.4),  wnile  tne  tnird 
staffe  is  the  only  function  of  tne  43202  chip  (Figure  3.5). 
Actually  eacn  stage  of  tne  pipeline  is  an  independent 
subprocessor ,  wni en  operates  until  tne  pipeline  is  full  and 
tuen  halts  and  waits  for  additional  wofk. 
a.   Instruction  Decoder 

Tne  first  subprocessor  of  tne  pipeline  is 
the  Instuction  Decoder  (ID),  which  performs  the  following 
functions: 


1.  Receives  macroinstruc tions . 

2.  Processes  variable  length   ields. 

3.  Extracts  logical  addresses. 

4.  Generates  starting  addresses  for  micro- 
instruction procedures 

5.  Generates  micro-instructions  for  simple 
operations. 


The  general  task  facing  the  Instruction 
Decoder  is  to  interpret  the  macro-instruction  stream,  to 
determine  which  micro-instruction  sequence  should  oe 
initiated  next  and  to  extract  logical  address  data. 
Additionally,  the  Instruction  Decoder  provides  a  mechanism 
to  recover  from  an  instruction  that  faults.  The  information 
necessary  for  fault  recovery  is  retained  by  the  Instruction 
Decoder  until  the  instruction  is  successfully  completed. 
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Figure    3.4  43id01     Biocli      Diagram. 

b.   Microinstruction  Sequencer 

Tne  second  subprocessor  in  tne  pipeline  is 
the  Microinstruction  Sequencer  (MS).  Tne  role  of  tne 
Microinstruction  Sequencer  is  to  decide  wnicn 
microinstruction  should  be  sent  to  the  Execution  Unit  for 
eaca  cycle. 
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c.   Iiecuiion  Ulil 

The  43202  contains  the  Execution  Unit'  (EU) 
which  is  third  sta^e  of  the  GDP  pipeline.  This  unit  receives 
microinstructions  from  the  43201  and  routes  them  to  one  of 
tne  two  independent  subprocessors  that  mafce  up  the  EU,  the 
Data  Manipulation  Unit  (DM[J)  or  the  Reference  Generation 
Unit  (RGO). 
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Figure   3.5  43202   Bloclc   Diagram. 

The  Data  Manipulation  Unit  contains  the 
registers  and  arithmetic  capabilities  necessary  to  perform 
hardware  recognition  of  eight  (B)  data 
types,   16,   and   32  bit  multiply,   divide,    and   remainder 
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operations.   Additionally  it  contains  tne  control   functions 
for  32,  64,  and  80  bit  floating  point  aritnmetic. 

The  Reference  Generation  Unit  provides  the 
translation  of  a  40  bit  virtual  address  into  a  24  bit 
physical  address,  a  hardware  enforced  domain  protection 
system  (read,  write,  alter,  accessed),  handling  sequencing 
for  8,  16,  32,  64,  and  80  bit  memory  accesses,  and 
controllng  tne  on-cnip  top-of-stacic  register.  In  general, 
the  Execution  Unit  manipulates  data  and  translates  tne 
logical  addresses  into  physical  addresses. 

d.   Processor  Paclcet  Bus  Definition 

Tne  Processor  Packet  Bus  contains  19  signal 
lines.  Sixteen  (16)  signal  lines  are  the  three-state 
Aldress-Control-Data  lines  (ACD15  througn  ACD0)  and  tne 
remaining  three  are  control  lines  used  to  request  the  bus, 
enable  the  buffers  for  output  from  and  an  interconnect 
status  line.  In  general  by  sending  tne  proper  signals,  tne 
system  bus  is  used  as  an  address,  control  or  data  bus.  The 
mechanism  for  tnis  multi-use  of  the  system  bus  is  quite 
complex  and  it  is  explained  in  Intel's  manuals. 
2«   interface  Processor 

The  Interface  Processor  (IP)  interfaces  the  GDP's 
and  the  employed  peripheral  subsystems  hy  providing  I/O 
facilities.  An  IP  maps  a  portion  of  the  peripneral  address 
space  into  the  iAPX  432  system  memory  via  four  (4) 
different   IP   windows   tnat  may  be   mapped   onto   four   (4) 
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different  objects  located  in  main  memory,  with  tne  same 
protection  mecnanisns  as  any  iAPX  432  processor.  Fie-ure  3.6 
Illustrates  tne  internal  arcnitecture  of  tne  Interface 
Processor. 
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Figure   3.6   Interface   Processor   Blocic   Diagram. 

D.   DATA  MANIPULATION 

1  •    I§.Il!iiI2  Eecof ni zed  Data  Tvgfis 

Computers  store  data  in  their  memory  in  terms  of 
zeros  and  ones.  What  these  strings  of  bits  represent  depends 
upon  the  interpretation  given  to  them  by  the  computer.  This 
■neans  tnat  two  or  more  different  pieces  of  information  might 
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be  represented  by  exactly  the  same  string-  of  oits  and  so 
tais  string  could  be  Interperated  as  an  instruction, 
integer,  or  character.  These  basic  representations  are 
called  hardware  recognized  data  types  and  nave  the  following 
characteristics: 


1.  Each  instance   of  a  type  is   an  addressable  unit 
of  memory. 

2.  Each  type  has   associated  with  it   a   set   of 
operations  that  can  be  performed  on  this  type. 


The  combination  of  all  the  hardware  recognized  data 
types  with  all  the  operators  which  act  upon  them  constitute 
the  instruction  set  of  the  computer.  These  hardware 
recognized  data  types  are  called  primitive  data  types 
because  they  are  used  to  construct  more  complex  data 
structures. 

The  Intel  432  recognizes  eight  different  primitive 
data  types,  which  are  divided  into  four  classes:  Characters, 
Ordinal  (unsigned  integers  16  and  32  bits  long),  Integer  and 
Real.  Figure  3.7  provides  the  formats  of  eacn  of  the  eight 
hardware  recognized  data  types  [Ref.  15j  . 
2-   Structured  Data  T2.2§i 

The  term  structured  data  types  is  used  for  ordered 
aggregates  of  primitives.  The  two  structured  data  types  that 
can  be  accessed  by  the  432  are  Arrays  and  Records.  Although 
not  supported  by  hardware,  the  432  provides  a  mechanism  that 
allows  structured  data  types  to  be  manipulated  easily. 
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3 .   Ins  true tions 

The  instruction  set  of  tne  43H  is  ricft  and  supports 
five  out  of  tne  six  operations  which,  according  to  ^yers 
[Ref.  10] f  a  language  directed  architecure  must  provide.  It 
supports  string  processing,  arithmetic  operations,  program 
flov,  error  handling,  and  program  tracing,  wnile  it  is 
missing  the  editing  operation.  In  addition,  it  supports 
segment  and  object  creation.  A  summary  of  tne  432 
instruction  set  is  contained  in  Myers  [Ref.  llj  . 

*  •   Ihs t ru c t i on  |o rmat 

The  instruction  format  of  the  432  has  four  fields. 
The  first  field  (class)  specifies  now  many  operands  are  in 
the  instruction.  The  second  (format)  specifies  now  the 
operands  are  to  be  accessed.  The  third  (reference)  specifies 
the  logical  addresses  of  up  to  three  operands.  Finally,  tne 
fourth  field  (operator  code)  specifies  the  operator.  The 
segment  selector  identifies  the  segment  that  contains  the 
operand,  while  the  displacement  locates  the  operand  witnin 
the  segment.  Figure  3.9  illustrates  tne  instuction  format. 

^  •   Alll^iiihg  f^lo aes 

The  base  and  index  values  are  used  to  locate  the 
operand  witnin  the  segment  eitner  by  containing  tne  value 
itself  (direct  addressing)  or  by  pointing  to  a  location 
which  in  turn  points  to  the  location  where  tne  value  of  the 
operand  has  been  stored  (indirect  addressing). 
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/     (Operator   j our! opr ! opr }  format  !  class  j      / 
/     Icode  field!  3  !  2  j  i  j   field  I  field  I     / 

0-5  bits    /  i)-306  \  10-4  bits!4-6bits  ! 
/    bits   \ 


'logical  address! 

/  \ 

/  \ 


I  segment  !  dispacement  1 
I  selector!  1 


/  \ 

/  \ 

1  base       1   index     ' 


Fiffure  3.S  iAPX  432  Instruction  Fornat  (tnree  operands) 

A  number  of  combinations  (base  direct/indirect  and 
index  direct/indirect)  of  direct  and  indirect  reference  are 
called  addressing'  modes.  The  system  selects  tne  most 
efficient  way  for  addressing  tne  various  data  types  as 
follows  : 

1.  Base  and  Index  Direct  :  used  to  access  scalars. 

2.  Base    Indirectt  Index   Direct   :   used   to   access 
records. 

3.  Base    Direct,   Index   Indirect  :   used    to   access 
static  arrays. 

4.  Base   and   Index  Indirect  :   used  to  access   dynamic 
arrays . 

Figures  3.9A  and  3.9B  illustrate  tne  four  addressing  modes. 
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Scalar:  Index  and  Base  Specified  Directly 
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Record:  Base  Specified  Indirectly 
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Figure  3.9A  Addressing  ^odes 

S  •   2£^Z1§S.^  S  ta ct 

A  special  data  segment  maintained  Dy  tne  Hardware 
for  expression  evaluation  is  called  tne  operand  staclc. 
Accesses  to  tne  top  of  tne  operand  stacK  are  called  irrplicit 
references  and  tne  items  are  added  to  or  removed  from  tne 
stacK:  on  a  last-in  first-out  (LIFO)  policy.  Tne  current 
stact  top  is  pointed  to  by  a  nardware  naintained  stack: 
pointer. 
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static  Array:  Index  Specified  Indirectly 
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Dynamic    Array:    Base   and    Index   Specified   Indirectly 
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Figure   3.9B   Addressing  diodes 
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7.   Instruction  Encoding 

An  effort  tias  been  to  speed  up  execution  throu^n 
instruction  decoding,  A  lar,8re  percentage  of  a  corputer's 
time  is  spent  fetching  instructions;  aence  tne  faster  the 
instuctions  can  be  fetcned  tne  less  time  will  be  spent 
waiting  to  execute  an  instruction. 

The  432  uses  bit-variable  instructions  versus  tne 
fixed-size  length  wnich  is  used  by  nnost  machines.  This 
flexibility  implies  tnat  there  is  no  constraint  for  the 
instructions  to  start  or  to  end  on  byte  or  word  boundaries. 
The  size  of  the  instructions  varies  from  6-bit  long  for  the 
shortest  up  to  344  bits  Ion?  for  the  longest  instruction. 
Another  difference,  in  the  instruction  encoding,  is  that  in 
instructions  lifce  A  =  A  -•■  B ,  the  operand  A  need  to  be 
referenced  only  once  since  the  format  field  in  the 
instruction  indicates  now  many  times  a  particular  operand  is 
used. 

E.   MEMORY  0R5ANIZATI0N 

The  term  memory  organization  comprises  two  distinct 
aspects  of  a  computer's  memory.  One  is  the  hardware 
structure  of  the  memory,  while  the  other  is  the  method  by 
which  the  memory  can  be  addressed. 

In  general  all  memory  is  structured  linearly,  differing 
only  in  the  number  of  bits  per  byte  and  the  way  a  byte  is 
addressed.  Memory  is  addressed  through  tne  address  pins  or 
tne  CPU,   Which  are  connected  to  the  decoder,  and  translated 
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to  addresses.  Since  there  are  no  saps  in  tne  sequence  of 
numbers  produced  by  tne  decoder,  any  memory  is  addressed 
linearly.  However,  if  you  looii  at  memory  from  tne  users 
point  of  view,  a  memory  is  said  to  be: 

1.  Linear   if  the  user  can  address  it  linearly. 

2.  Segmented  if  the  user  can  address  olcclrs  of 
linear  address,  where  each  snace  is  called  a 
segment. 

Bach   item   within  a   segment  is   addressed   by  a   two 
component  address: 

1.  The  segment  selector  which  specifies  the  seerment. 

2.  The   displacement  wnich  specifies   the   offset   from 
the  base  of  the  segment  to  the  item  beine  selected. 

1 .   Ml22ih£  S egmenied  MemaiZ 

In  general,  mapping  is  performed  via  the  segment 
discriptors  that  are  maintained  in  the  segment  table.  Each 
segment  has  a  corresponding  segment  descriptor  which 
contains  the  starting  physical  address  and  the  length  of  the 
segment.  This  mapping  is  illustrated  in  Figure  3.1t5. 

The  segment  selector  of  a  logical  address  is 
used  as  an  index  to  select  a  segment  descriptor  in  the 
segment  table.  The  displacement  is  added  to  the  segment 
starting  address  to  produce  the  physical  address  of 
the  operand  being  referenced.  Additionally,  displacement 
is  easily  checked  by  the  hardware  to  ensure  that  the 
reference  does  not  exceed  tne  length  of  tne  segment. 
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Figure  3.10  Se/?mented  Mapped  Memory. 

2»   Structured  Memory 

Tne  Intel  432  nas  segfnented  memory  wnicn  is 
different  from  tne  segmented  memories  of  otner 
microcomputers  as  follows: 


Tne  Intel  432  can  address  up  to  2="'24  segments. 
Eacn  segment  can  be  up  to  2'!'^16  bytes  long. 
Tfterefore,  tne  total  virtual  address  space  is 
2^*40  bytes. 

Tne  Intel  422  uses  a  two-step  mapping  process 
tnat  separates  segment  relocation  and  access 
control . 


For   tfiese   reasons   Intel   refers  to  tne  432's  memory  as 
structured  memory. 

Two-Step  Mapping:  The  access  mapping,  being  similar 
to  one-step  segment  mapping  process,  is  illustrated  in 
Figure  3.11  and  it  is  performed  as  follows: 
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1.  The  segment  selector  part  of  a  lofficai  adaress 
Is  used  as  an  index  into  tne  access  segment  to 
select  one  of  tne  access  descriptors,  wcica 
contain   access  rights  data. 

2.  Tne  access  descriptor  then  acts  as  an  index  into 
the  seffment  table  to  select  a  segment 
descriptor. 

3.  The  displacement  is  added  to  the  segment 
starting  address . 


Although  .there  are  several  segment  types,  the  two 
fundamental  types,  called  base  types,  are  tne  data  segments 
which  contain  hoth  data  and  instructions,  and  the  acress 
segments,  wnicn  contain  only  access  descriptors.  £acn  base 
type  is  divided  into  several  nardware  recognized  system  .pa 
types.  For  example,  data  segments  are  divided  into 
instruction  segments  and  stacjc  segments. 
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Figure   3.11   Two-Step   r^apping. 
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Since  two-step  mapping  process  separates  segment 
relocation  from  access  control,  tne  type  information  is 
contained  in  the  segment  descriptor  while  the  access 
information  is  contained  in  the  access  descriptor.  This 
organization  allows  tne  division  of  protection  into  user- 
specific  protection  (access  rights)  and  segment-specific 
protection  (segment  type  protection). 

Each  program  module  is  supplied  at  run-time  with  a 
collection  of  segment  numbers  for  only  those  segments  it 
needs  to  access  during  execution.  These  segments  determine 
the  access  environment  and  they  are  stored  in  a  collection 
of  access  segments. 

The  advantages  one  can  view  in  the  two-step-mapping 
can  be  summarized  as  follows: 


1.  It   taices  fewer  bits  in  an  address  to  specify  a 
segment  (as  few  as  four  bits). 

2.  It   restricts  tne  number  of  segments  accessible 
by  a  given  program. 

3.  It  separates  tne  protection  features  into  access 
and  type  protection. 


One  potential  problem  with  tne  two-step  mapping  is 
the  access  time.  To  speed  up  tne  process,  Intel 
maintains  an  associative  cache  tnat  stores  recently  used 
segment  descriptors,  access  descriptors,  and  the  addresses 
of  a  number  of  commonly  accessed  items. 
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3»   Object  Referencingj.  Addressing  aad  Pratecil^n 

In  eitner  tfte  single  or  the  multiuser 
environment  objects  need  protection  from  the  user  wno  might 
inadvertently  use  an  object  in  a  way  that  it  was  not 
intended  to  be  used  and  from  programs  that  might  destroy  the 
object.  Additionally,  in  a  multiuser  environment  when 
several  users  require  simultaneous  access  to  the  same 
object,  at  least  two  more  problems  can  arise: 


1.   Access  Rights:   Not   all  the  users  need  to   have 
tne  same  access  rights. 


2.  Exclusive  access:  One  user  may  require 
exclusive  access  to  that  object  for  a  particular 
operation  to  ensure  that  no  other  processor 
alters  tne  object  while  tne  operation  proceeds. 


These  problems  are  solved  in  the  432  architecture  by 
the  use  of  tne  access  descriptors. 

^»   Access  Descrl2tors 

Each  object  has  its  own  access  descriptors  which 
act  as  both  priviiedge  and  protection  permits  for  the 
object.  Many  access  descriptors  can  exist  for  the  same 
object.  Each  access  descriptor  belongs  to  some  (but  may  be 
copied  and/or  passed  to  another)  procedure  (context),  and 
defines  the  access  rights  of  the  procedure  using  this 
Object.  A  procedure  can  reference  a  segment  of  memory  if  and 
only  if  it  holds  an  access  descriptor  for  that  segment.  Tne 
basic  rights  accorded  the  procedure  by  the  access  descriptor 
can  be  read  only,  write  only,  both  or  none. 
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5.   Segments  versus  ObJ^ects. 

An  object  can  be  a  contiguous  subsection  of  a 
segment  or  it  can  consist  of  a  single  segment,  or  collection 
of  segments.  Figure  3.12  illustrates  tne  relation  between 
segments  and  objects. 

Tne  term  segment  refers  to  tne  physical 
structure  of  tne  data  in  memory  while  tne  term  object  refers 
to  tne  logical  structure  of  tne  data  in  memory.  Viewing  an 
Object  as  a  sinele  entity,  its  root  seement  specifies  tne 
beginning  of  the  object  while  the  descriptor  segment  tnat 
points  to  this  root  segment  is  considered  as  pointing  to  tne 
whole  object.  Such  a  segment  descriptor  is  called  object  .pa 
reference,  wnile  tne  segment  table  containing  object 
references  is  called  object  table. 
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riffure  3.12  Relation  among  Objects  and  Segments. 

F.   OPERATING  SYSTEM 

Tne   unique   item   in   tne   432   arcitecture   is  tne  way 
its  operating  system  is  implemented.  Tnere  are  two  distinct. 
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not  self-compiete  but  cooperating,  operating  systems,*  one  is 
implemented  in  Hardware  and  is  called  tne  Silicon  OS,  -wr.iie 
the  other  is  a  collection  of  Ada  packages  available  to  the 
user  for  furtner  .Tiodification  as  required,  and  called  tne 
iMAX  OS.  Figure  3.13  illustrates  the  mechanisms  implemented 
in  tne  Silicon  OS  and  the  cooperating  iMAX  OS  as  well  as  tne 
conventional  architecture  level  and  the  user  interface 
level . 
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Figure    3.13   Silicon  and    iMAX   OS's. 

!•   Ill§  Silicon  OS 

A   number   of   resource   management   mechanisms   are 

implemented   in  tfie  nardware,   wnile  tne  resource  managment 

policies  are   established  by  software   in   iMAX  OS.   These 

mechanisms   are  wnat   Intel  calls   the  Silicon  OS,   wnicn 

consists    of   a   memory   resources   manager   and  processor 
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resources  manager.   Tne  Tiecnanlsms  supported  by  me   Siiion 
OS  are  illustrated  in  figure  3.13. 
2.   iMAX  OS 

The  iMAX  OS  is  a  collection  of  Ada  pacta^es  provided 
in  two  different  subsystems.  Tne  users  can  select  tne  one 
best  tailored  to  their  applications: 

a.  Full  iMAX  provides  run-time  support  including 
dynamic  storage  management,  avnamic  process 
manaeement,  and   I/O  interface. 

b.  Minimal  iMAX  is  a  subset  of  full  IMAX  and 
supports  the  execution  of  multiple  processes 
on  a  multiprocessor  environment.  It  does  not 
support  dynamic  storage  and/or  process 
management  and  I/O  except  through  the  DEBUG- 
432  debuffffer. 

Tne  only  compiler  that  generates  code  for  the 
432  is  the  Ada  compiler  provided  by  Intel.  Although  this 
forces  programmers  to  use  only  the  Ada  language  for  writing 
programs  running  under  the  432,  it  allows  them  to  maice  easy 
calls  to  the  iMAX  pacsafi:es  by  usinar  the  Ada  provided 
facilities,  such  as  tne  environment  pragma,  with  clause  and 
use  clause. 

Two  Kinds  of  processes  can  be  controlled  by  iMAX; 
the  static  processes  which  are  created  by  the  user  at 
system  initialization  and  tne  dynamic  processes  wnich  are 
created  dynamically  by  the  system  and  then  -ntered  into  the 
ready  state.  The  minimal  iMAX,  wnich  does  not  support 
dynamic  operations,  requires  only  47K  of  memory  compared  to 
290K  for  tne  full  iMAX. 
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Tile  iMAX  pacfca^ss  manage  and  enhance  ihe  432's 
interprocess  communicailon ,  data  transfers  ceiween 
peripheral  devices  and  the  432  central  system,  and  allows 
the  users  to  configure  and  control  a  number  of  General  Data 
Processors  and  Interface  Processors,  static  user  processes, 
and  I/O  device  interfaces. 

5.   PROGRAM  STRUCTURE 

In  most  computer  systems  program  structure  is  part  of 
the  operating  system  or  tne  language  run-time  envirorimem 
and  there  is  no  need  for  tne  program  structure  to  be 
included  in  tne  description  of  tne  architecture.  However,  in 
the  Intel  432,  the  program  structure  is  part  of  the 
arcnitecture  and  contains  tne  following  objects: 


1.  Processor  Objects 

2.  Process  Objects 

3.  Context  Objects 

4.  Instruction  Objects 

5.  Data  Objects 


1  •   Processor  0 b j.^ c t 

A  previous  section  specified  that  the  processors  in 
a  multiprocessor  environment  are  hardware-recognized 
objects  and  that  object  is  a  data  structure  in  memory.  It 
is  logical  therefore  to  asK  how  can  a  GDP,  made  of  silicon 
and  sitting  on  a  pc  board,  where  it  fetches  and  executes 
instructions,  be  a  data  structure  in  memory? 

The  physical  processor  is  not  an  object.  However, 
each   physical   processor  does   nave  an   object   fa  data 
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struciure  in  memory)  associated  with  it  which  is  called  a 
processor  object.  The  processor  object  is  an  abstract 
representation  of  the  GDP  and  is  in  one-to-one 
correspondence  with  the  GDP.  It  can  reside  anywhere  in  the 
memory  and  can  be  dynamically  relocated  if  necessary. 
Addressed  by  its  associated  processor  via  an  on-cnip 
reference,  the  processor  object  provides  the  means  to  assign 
the  processor  it  represents  to  a  particular  process  set.  It 
also  serves  to  record  information  about  the  physical 
processor  such  as  its  state  (running  or  halted),  diagnostic 
information  and  references  for  other  objects  tne  processor 
needs.  Additionally,  it  contains  an  object  reference  for  the 
process  object  currently  running  on  the  processor.  Tnis 
reference  chances  in  time  as  the  processor  switches  amonj? 
different  processes.  Tne  processor  object  is  depicted  in 
Figure  3.14  with  the  operations  which  act  upon  it. 

Remember  that  the  GDP  is  a  three  stace  pipeline 
processor  which  consists  of  two  chips,  eacn  one  of  which  nas 
two  subprocessors.  If  the  programmer  tries  to  fceep  all  of 
these  details  in  mind  as  well  as  tne  flow  of  information  and 
the  data  manipulation,  while  writing  a  program  statement, 
complexity  and  confusion  will  reign.  However,  if  the 
programmer  considers  that  a  processor  exists  which  can 
perform  a  set  of  operations,  programming  is  simpler. 
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2«   Process  0  6j_ect^ 

A  process   is   a   locus  of  control  wlttin   an 
instruction   sequence.   Tnat  is,   a  process  is  tne  abstract 


Send  to  processor (inst) > 

(inst) > 

(inst) > 


Broadcast  to  

processor 
Read  processor  

status  and  clocK 
Requalify  process (nard) > 


Select  processor- 
Start  processor- 


Create  processor- 
object 


•(nard) > 

(nard) > 

(soft) > 


processor 
object 


Legend:   inst   =  operation   is   a  macnine   Instruction 

(operator) . 

nard  =  operation  is  performed  by  nardware  as 
a  result  of  conditions  detected  by 
tne  processor. 

soft  =  operation  may  be  implemented  toy 
software  (e.^.  an  operating  systemK 

Figure   3.14   Processor  Object. 


entity  wnicn  moves  througn  tne  instructions  of  a  procedure 
as  tne  procedure  is  executed  by  the  processor.  Given  tnis 
definition  for  a  process  object,  now  can  a  sequence  of 
operations  be  an  object?  Tne  process  is  not  an  object*  out 
eacn  process  does  nave  an  object  associated  witn  it  wnirn  is 
called  a  process  object.  Tne  process  object  contains 
information  concerning  now  tne  process  snould  be  scnenuled 
and  wnat  is  tne  process  status  (running,  waiting,  etc.). 
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The  slffnificance  of  tne  existence  and  tne  use  of 
tiie  object  reference  is  tnat  tne  432's  object  oriented 
addressing  and  protection  mecftanism  does  not  allow  a 
processor  to  access  an  object  unless  it  nas  an  object 
reference  for  it.  T&e  object  reference  from  tne  processor 
object  to  the  process  object  changes  dynamically  in  time  as 
the  processor  switches  among  different  processes.  Each 
process  has  its  own  process  object.  The  processes  may  snare 
the  same  processor.  Figure  3.15  indicates  operations  on  a 
process  object. 

read  process  clocic (Ints)  — 

enter  global  segment (inst)  — 

get  state  information (hard)  — 

save  state  information (hard) — 

dispatch  process (hard)  — 

set  scheduling  parameters (soft)— 

create  process  object (soft)  — 

Figure  3.15  Process  Object. 

3.   Context  Objects 

Procedures  (e.g.  SOOAREROOT  X  )  are  shared  among 
several   different   processes  by  giving  eacn  process  a   copy 

(an  instance)  of  the  proceaure.  Each  instance  of  a  procedure 
(eacn  copy)  is  called  a  context. 


->! 

-> 

process 

-> 

object 

-> 

■-> 

•-> 

-> 
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A  contexx  object  contains  information  about  a 
particular  invocation  of  a  procedure.  Tnis  means  tnat  mere 
are  as  many  context  objects  for  tne  same  procedure  as  there 
are  invocations  of  tne  procedure.  Tne  information  tnat  a 
context  contains  includes  tne  instruction  pointer  for  tnis 
context,  tne  stact  pointer  for  tnis  context's  stack:,  the 
return  linit  to  ihe  calling  context,  and  references  for  all 
tne  objects  tnat  can  be  accessed  by  tnis  context. 

Figure  3.16  depicts  a  context  object  and  tne 
operations  wnicn  act  upon  it.  The  complete  list  of  objects 
currently  accessitJle  by  tne  procedure  is  called  its  access 
environment.  The  432's  object-oriented  protection  mechanism 
does  not  allow  a  program  to  access  an  object  unless  it  nas  a 
reference  for  tnat  object.  Thus  in  tne  context  one  can  only 
access  objects  that  are  listed  in  the  access  environment, 
and  tne  access  environment  changes  only  if  tne  current 
context  calls  another  procedure  because  tne  called  procedure 
nas  a  different  context  and  nence  a  different  list  of 
objects  that  can  be  accessed.  This  places  the  protected 
access  environment  at  tne  procedure  level,  instead  of  the 
process  or  Job  level  as  on  most  systems. 
-•   Ih  struct! on  Ooj^ect 

An  instruction  object  nas  two  major 
Characteristics: 


1,   It   can  only  nold  instructions  (and  a  little 
bit  of  system  information)  and  never  lata. 
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2.  It  is  tne  only  type  of  object  mat  a 
processor  will  use  as  a  source  of 
instructions  to  be  fetched  and  executed. 


Call (inst ) > 

Call  with  message (inst) > 

Return (inst) > 

Create  context (inst) > 

object 
Create  context (hard) > 

data  segment 
Create  operand (nard) > 

staclc 
Destroy  context (hard) > 

Garbage  collection (soft) > 


context 


object 


Figure  3.16  Context  Object. 

This  second  feature  implies  that  the  4:32's 
object-oriented  protection  mechanism  will  never  allow  any 
other  iclnd  of  object  (proccess  object,  data  object,  etc.}  to 
be  accidentally  mistaken  for  instruction  and  thus  executed. 
This  isolation  of  tne  instructions  provides  tne  advantage 
that  all  4:32  programs  are  fully  reentrant. 

Instruction   objects   can  be  snarea   by   several 
instances  of  a  program.  Figure  3,1?  indicates  an  instruction 
object  and  tne  operations  wnich  act  upon  it. 
5.   Data  Obj.^cts 

Data  object  is  an  object  that  holds  data  (e.g. 
integers,  reals,  cnaracter,  tables,  etc.).  The  432  provides 
a   mechanism   for  assigning  lata  objects  (as  well   as   other 
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objects)  a  software-defined  type.  Tnis  is  anotner  proieciion 
mecbanism  wnicft  ensures  tnat  tne  ooject  will  oe  manipuiatei 
by  instructions  of  tne  proper  type. 


Call  context- 


Call  context 

with  message 
Return  


Branch  intersegment 

Branch  intersegment 

and  lint 
Branch  intersegment 

without  trace 
Execute 


(inst)- 

(inst)  — 
(  i  n  5 1 )  — 
(inst  )  — 
(inst)  — 
(inst)- 
(hard  )  — 
(sof  t)  — 


instuction 


0  bject 


Figure  3.17  Instruction  Object. 

6.   SuoiinilZ  It   i&§  Structure  of  a  Program 

Figure   3. IB   summarizes   the   important   points 
about  each  object  of  tne  program  structure. 

H.   INTERPROCESS  COMMUNICATION 

It  has  been  said  that  one  of  the  salient  characteristics 
of  the  4:32  is  its  capability  to  support  multiprocessing  in  a 
multiprocessor  environment.  In  other  words  the  system 
provides  for  concurrent  programming.  The  mechanisms  that 
support  concurrent  programming  are  quite  complex  and  Include 
the  use  of  Communication  Ports  Objects,  Domain  Objects,  and 
Dispatcning  Port  Objects.   Following  an  explanation  of  tnese 
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TProcessoFT 


Pnysical  Processor 
-Made  of  Silicon  (not  an  oDject) 
-Fetcnes  and  Executes  Instructions 


Memory 
Space 


(Processor! 
1  Object   ! 


i  Process  ' 


Object 


I  Context  I 


Object 


Instruction  I 
I 
I 


Object 


Tne  above 


v 
I 


Data 
Object 


-T 

r 
I 
I 


Processor  object 

-fiacn  processor  has  one 

-Gontains  information  sum  as: 

-Processor  status  {es,    running,  naltel) 
-Diagnostic  and  macnine  cnecK  ini'ormat. 
-Reference  for  the  process  currently 
being  executed 


Process   Object 

-One  for  eacn  process  in  tne  system 

-Contains  information  such  as: 

-Process  status  (eg,  running,  halted) 
-How  tne  process  snould  be  scneduled 
-Reference  for  the  context   currently 
beinff  executed 

Context  Object 

-One  per  eacn  instance  of  a  procedure 

-Contains  information  such  as: 

-Instruction  pointer  for  this  object 
-StacK  pointer  for  this  context's  stacic 
-Return  linic  to  the  context's  stacK 
-Reference  for  all  the  objects  that  can 
be  accessed  by  this  context 


Instruction  Object 

-Contains  only  instruction  and  no  data 
-It  is  the  only  type  of  object  that  a 
processor  uses  as  a  source  of 
instructions  to  be  fetched  and 
executed 


are  tne  hardware  recocnized  objects 


Data   Object 

-Contains  Data  (eg,  integers, 
characters  or  a  combination 
primitive  data    types) 


reals  , 

of   several 


Fiffure   3.18   Summary   of   the   Program   Structure. 
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objects,  a  simplified  example  will  be  presented  for  a 
general  understanding  of  tne  mecnanism  ttiat  supports 
concurrent  programming. 

1 .   Communica  tion  Port 

A  communication  port  is  tne  communication  medium 
between  two  async&ronously  communicating  processes.  Eacft 
communication  port  is  represented  Dy  an  object  ^^nicn 
contains  information  on  messages  tftat  are  sent  to  processes. 
Figure  3.19  indicates  operations  on  a  communication  port 
object. 


Send 

Conditional  send- 
Surrogate  send — 
Receive 


(inst 

(inst 

( inst 

(inst 


Conditional  receive (inst 

Surrogate  receive (inst 

(nard 

(nard 


Message    buffer- 
full   cnecic 
Enqueue   message 


—  (hard 


Enqueue  carrier 

to  port 
Create  port (soft 


Priority  message- 
enqueue 
Multiple  wait 


(soft 
(soft 


communication 


port 
object 


Fiffure        3.19  Communication  Port   Object 
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The   communicalion   ports,   by  acting   as   a   buffer 
tetvsen   two  asyncftronous  processes,   allow  eacn  process   to 
proceed  at  its  own  rate. 
2.   Domain  Objects 

Inbedded  in  the  features  of  Domain  Objects  are  the 
concepts  of  static  and  dynamic  objects.  Tne  concept  of 
dynamic  objects  has  been  already  encountered  in  Section  G.3, 
where  the  context  objects  are  examined.  Recall  that  the 
access  environTient  consists  of  objects  for  wni  ch  an  object 
reference  exists  in  the  list  of  the  current  context  object. 
Additionally,  tne  access  environment  changes  dynamically 
when  a  procedure  is  called  by  a  context  and  the  access 
environment  is  now  the  list  of  the  new  current  context. 
Since  the  objects  accessible  by  the  process  cnange 
dynamically  in  time,  ttie  objects  pointed  to  by  tne  current 
context  object  vary  in  time.  Therefore  tne  space  tney  occupy 
in  memory  is  deallocated  once  tney  are  not  accessible  by  the 
proccess.  Hence  tnese  objects  are  dynamic  objects.  In 
contrast  static  objects  are  those  whose  memory  space  is 
never  deallocated  regardless  of  whether  they  are  accessible 
or  not.  In  summary,  a  context  object  is  also  a  list  of 
dynamic  objects  while  a  domain  is  a  list  of  object 
references  for  all  tne  static  objects  used  by  a  module. 

In  the  object-oriented  decomposition  metnod,  the 
criterion  for  modularization  is  for  eacn  module  to  niae  a 
desi?n   decision.   In  order  to  carry  out  its  tasK,   a  module 
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migai  consist  of  more  tnan  one  procedure  wnlcn  in  turn  migni 
need  to  access  some,  aii  or  none  of  the  static  objects  usei 
by  tne  module.  Tni s  is  tne  reason  a  domain  contains  a  list 
of  object  references  to  ail  static  objects  of  tne  module. 

Tne  reason  objects  associated  witft  tne  modules 
are  called  domains  is  tnai  tne  module  tney  represent  confine 
knowledge  of  tne  object  structure  witnin  a  specified  domain. 
Figure  3.20  depicts  a  domain  object  and  tne  operations  wnicn 
act  upon  it. 


Call  conte x t ( i n s t )  — 

Call  context (  i n s  t )  — 

with  message 
Return ( i n s  t )  — 

Create  context (hard)  — 

Crea  te  domain (sof  t  )  — 

Figure  3.20  Domain  Object. 


> 

domain 

> 

> 

object 

> 

> 

Networks  of  domains,  where  eacn  domain  nides  tne 
representation  of  an  object,  represent  the  static  structure 
of  a  4:32  proe-ram.  Some  of  tne  domains  maice  use  of  objects  in 
other  domains  in  the  networic  to  create  a  more  complex 
object . 

If  a  module  (represented  by  a  domain  object) 
needs  to  use  procedures  provided  by  another  module,  tne 
first  module  must  nave  a  reference  for  the  domain  that 
represents   the   second  module.   The  domains  can   be   viewed 
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either  from  an  outside  or  inside  point  of  view.  Consequently 
procedures  can  be  executed  inside  or  outside  of  tne  domain, 
this  prevents  static  objects  of  tne  domain  from  being 
accessed  by  ail  procedures  tnat  use  this  domain. 

In   this  case  tne  static  objects  are  divided   as 
follows  : 


1.  Private    objects   -   accessible   only    by 
procedures  inside  tne  domain. 

2.  Public   objects  -  accessible  by    procedures 
botn  inside  and  outside  tne  domain. 


Let  us  assume  the  situation  where  a  procedure 
(of  a  module)  is  currently  executing.  This  procedure  uses 
tne  same  domain  object  which  represents  tne  module  tnat 
belongs  to  the  procedure.  In  this  case  we  say  the  procedure 
is  executing  inside  tne  domain.  Tne  same  proced\:re  needs  to 
mate  a  call  to  another  procedure  not  belonging  to  its 
module.  For  this  to  be  achieved  tne  first  module  must  nave  a 
reference  to  the  domain  representing  the  module  of  the 
callee.  After  this  object  reference  is  established  tne 
caller  can  use  the  static  objects  only  in  the  public  domain 
of  the  callee.  In  this  case  the  procedure  is  executing 
outside  the  domain. 

3.   Dispatching  Port  Objects 

Tne  dispatching  port  object  consist  of  two 
queues  tnat  serve  to  matcn  processes  witn  processors.  It  is 
the    object    that   is   used    to    implement    transparent 
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multiprocessing.   Figure   3.21  Indicates  a  dispatcnin?   port 
object  and  toe  operations  wnicn  act  upon  it. 


Dispatcnin^  port' 


(nard) > 

(nard) > 


dispatcninff 

port 
object 


Scneduie  process 

object 
Enqueue  processor (nard) > 

object  I 

Create   dispatcning (soft) >!  i 

port  

Figure        Z.'dl   Dispatcning  Port   Object 

4.      Exa.Tiple    of  Intgrprocoss   ComQuni^aiion 

Consider  a  program,  CHAT,  w&ich  consists  of  two 
subprograms  TED  and  JOHN.  ProeraTi  TED  writes  a  report  and 
ttien  sends  it  to  program  JOHN  to  type  it  which  in  turn  sends 
it    baci   to   TED  for  proofreading.      Wnen   tne  report    is    correct 

TED    prints    it. 

Tne   subprograms   TED  and  JOHN  will  be   tne   two 

processes  of  CHAT  which  can  start  execution  independently  in 
two  different  processors  of  tne  system.  For  simplicity  let 
us  consider  tnat  TED  starts  execution  first  and  begins  to 
write  its  report.  When  it  is  finished,  JOHN  has  been 
executing  and  it  is  ready  to  recieve  TED's  report  for 
typing. 

The  mechanism  for  sending  the  report  from  TED  to 
JOHN  is  the  communication  port  wnicn  acts  as  a  buffer 
between  the  two  asynchronous  processes,  allowing  each  to 
proceed  at  its  own  rate.  Two  communications  ports  are  needed 
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for  our  example.  One  is  TED's  receiver  and  JOHN's 
transmitter  wniie  tne  otner  is  JOHN's  receiver  ana  TJilD'S 
transmitter.  Figure  Z,2'^  illustrates  tne  communication 
between   TED  and  JOHN. 


draft        ' 
reports    > 


COMM.        \ 


\ 


I    draft        \    j    TED's               \  1    draft        \ 

i    reDorts   /    '      receiver     /  '    reports   / 
/          / 

PORT  / 


tec's       ! 
Object      I 


I      JOHN'S      ! 


object 


/   COMM. 


/   typed        I    /  JOHN'S        !  /   typed 

\  reports    '    \   receiver    '  \   reports 

\_— \ \ 

\   PORT 


Figure  3.22  Interprocess  Communication 

Tne  processes  TED  and  JOHN  intercftanse  messaees 
via  tne  com-nuni  cation  ports  and  tne  operations  SEND  and 
RECEIVE  defined  on  tne  communication  port  object  bear  tfte 
burden  of  tnat  intercommunication. 

The  instruction  SEND  nas  two  operands.  One  is 
tne  message  itself  and  tne  otner  is  tne  communication  port 
where  the  message  is  bein^  sent.  Before  the  SEND  is  executed 
tne  process  nas  a  message  it  wants  to  send.  After  SEND  is 
executed,   the   message   nas  been     sent   to   the   specified 
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communication  port.  For  efficiency,  only  the  object 
reference  is  copied. 

Ttie  RECEIVE  instruction  nas  one  operand,  tne 
communication  port  wnere  tne  message  is  to  be  received. 
Before  RECEIVE  is  executed  there  is  a  messasre  waiting  in  the 
com-nunication  port.  After  RECEIVE  is  executed,  tne  message 
is  moved  from  the  port  to  the  process  executing  the  RECEIVE. 

Again  only  the  object  reference  is  copied.  In  tne  case  a 
RECEIVE  instruction  is  executed  without  a  message  in  the 
communication  port,  the  process  waits  until  a  message  is 
sent . 

I.   A  3ASIC  I/O  ^ODEL 

Another  complicated  mechanism  in  tne  432  arcnitecure  is 
the  I/O  operation.  Here  we  examine  the  basic  means  for 
performing  an  I/O  operation  as  well  as  tne  very  basic 
implementation  mechanisms  needed  for  I/O  operations. 

A  peripheral  subsystem  is  an  autonomous  computer  system 
with  its  own  local  memory,  I/O  devices  and  controllers,  at 
least  one  processor,  and  software.  The  number  of  peripheral 
subsystems  employed  in  any  siven  application  may  be  varied 
with  Changing  needs,  independent  of  the  number  of  GDFs  in 
the  system. 

To  support  the  transfer  of  data  through  tne  wall  that 
separates  a  peripheral  subsystem  from  the  main  system,  tne 
Interface  Processor  (IP)  provides  a  set  of  software- 
controlled   windows.   A   window  is  used  to  expose   a  single 
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ot)Ject      in     main    system  memory   so    tftat    its   contents      nay      be 
transferred    to   or  from   tne   peripnerai    subsystem. 


Mam    System 


■>!    Process    ! > 


{Service   Reply 


I  Service  Requested ! 


^lessage 


Messaj?e 


— > 


Periptieral 

Subsystem 

Interface 


•> 


I 


{Service  Reply! 
I    Message    ' 


Service  Requested 


I    Message 


Device    Interface    !  <■ 


!    I/O    ! 


Peripnerai  Subsystem 


Figure  3.23  Peripnerai  Subsystem  Interface. 

The  IP  also  provides  a  set  of  functions  tnat  are  invoked 

by   software.   Tney  generally  permit  objects  in  main  system 

memory    to    be   manipulated   as    entities,    and  enable 
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communication  between  Tiain  syste^i  processes  and  software 
executing  in  a  peripheral  subsystem.  Figure  3.23  snows  tne 
peripneral  subsystem  interface. 

A  device  interface  is  considered  to  be  the  hardware  and 
software  in  tne  peripheral  subsystem  that  is  responsible  for 
manaffinff  an  I/O  device.  A  message  sent  from  a  process  that 
needs  an  I/O  service  contains  information  that  describes  the 
requested  operation  (e.s.  "read  file  XYZ").  The  device 
interface  interprets  the  message  and  carries  out  the 
operation.  If  an  operation  requests  input  data,  the  device 
interface  returns  the  data  as  a  message  to  the  originating 
process.  Tne  device  interface  may  also  return  a  message  to 
positively  acinowledge  completion  of  a  request. 

Tne  IP  is  connected  to  the  peripheral  subsystem  bus  as 
if  it  were  a  memory  component;  it  occupies  a  blocs  of  memory 
addresses  up  to  64K  bytes  long,  figure  3.24  illustrates  the 
peripheral  subsystem  hardware. 

The  Attached  Processor  (AP)  and  the  IP  interact  with 
each  otner  by  means  of  address  references  generated  by  tne 
AP  and  interrupt  requests  generated  by  the  IF.  At  any  given 
time,  the  IP  controller  is  represented  in  mam  memory  by  a 
process  object  and  a  context  object.  LlKe  a  GDP,  the  IP 
itself  is  represented  by  a  processor  object. 

When  supporting  multiple  process  environments,  the  IP 
controller  selects  the  environment  in  wni en  a  function  is  to 
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<===> 


Figure  3.24  Peripnerai  Subsystem  Hardware 

be  executed.  If  an  error  occurs  while  the  IP  controller  is 
executing  a  function  on  benalf  of  one  device  interface,  that 
error  is  confined  to  the  associated  process,  and  processes 
associated  with  other  device  interfaces  are  not  affected. 

I.   WINDOWS 

Every   transfer   of  data  between  the  main  system   and   a 
peripheral   subsystem   is   performed  with  the  aid  of   an   IP 
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window.  A  window  defines  a  correspondence,  or  mapping, 
between  a  subrange  of  perlpneral  subsystem  memory  addresses 
wltbln  the  ranee  of  addresses  occupied  by  tne  IP  and  an 
object  In  main  system  memory. 

The  action  of  the  IP,  In  mapping  the  peripheral 
subsystem  address  to  tne  main  system  object,  is  transparent 
to  the  aeent  maKlne  the  reference?  as  far  as  it  is 
concerned,  it  Is  simply  reading  or  writing  local  memory. 
Since  a  window  is  referenced  llKe  local  memory,  any 
Individual  transfer  may  be  between  an  object  and  local 
memory,  an  object  and  a  processor  register,  or  an  object  and 
an  I/O  device. 

There  are  four  IP  windows  that  may  be  mapped  into  four 
different  objects.  The  IP  controller  may  alter  the  windows 
during  execution  to  map  different  subranges  and  objects.  A 
fifth  window  provides  the  IP  controller  with  access  to  the 
IP's  function  facility.  By  writing  operands  and  an  opcode 
into  predefined  locations  in  this  window's  subrange,  the  IP 
controller  requests  the  I?  to  execute  a  function  on  its 
behalf.  Upon  completion  of  the  function,  the  IP  provides 
status  Information  that  the  IP  controller  can  read  tnrough 
the  window. 

Since  there  is  a  finite  number  of  windows,  most 
applications  will  need  to  manage  them  as  scarce  resources 
that  will  not  always  be  instantly  available.  This  means  that 


73 


at  least  some  I/O  device  transfers  will  nave  to  be   buffered 
in  local  memory  until  a  window  becomes  available. 

L.   TRANSPARENT  MDLTIPROCESSING 

Tfte  Intel  432  is  especially  designed  to  support  parallel 
execution  of  programs  by  multiple  processors.  Absolutely  no 
software  changes  are  required  to  move  programs  frorr  single 
processor  systems  to  multiple  processor  systems  or  vice 
versa . 

Tne  first  advantage  of  transparent  multiprocessing  is 
flexibility  provided  by  a  macnine  tnat  o  fers  a  ran^e  of 
performance.  Processors  can  be  added  to  or  removed  from 
tfte  configuration  to  meet  tiie  desired  performance  or  price. 
Tne  second  advantage  is  reliability,  because  if  one 
processor  fails,  the  rest  of  the  system  may  be  able  to 
continue  running.  In  fact,  luring  a  bencnmaric  performance 
test,  one  slot  in  tne  system  motnerboard  prevented  an 
assigned  GDP  from  being  initialized  and  tne  system  continued 
to  execute. 

1 .   Tne  Tnree  S tage s  of  Processor  ^ini^emen t 

Tne  effective  management  of  multiprocessing  in  a 
multiprocessor  environment  requires  Policy  Maicing, 
Scneluling,  and  Dispatcning. 

a.   Policy  Malting 

Policy  Maying  establishes  tne  criteria  tnat 
determines  iiow  processes  snare  processors.  These  criteria 
are   defined   by   tne  user,   via  tne  iMAX   OS,   at   system's 
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initialization.  The  iMAX  OS  passes  this  inforrraticn  to  the 
Silicon  OS  for  implementing  tne  policy  mechanism. 

Options  that  can  be  selected  to  irrpiement 
processor  sharing  are  first  -  come  -  first  -  serve  (FIFO), 
round  robin,  priority,  and  leadline  weighted.  Tne  user  can 
select  the  one  which  meets  the  applications  reaui rements . 

The  Policy  Maicing  requires  tne  user  to  set 
the  scheduling  parameters  by  answering  questions  such  as:  By 
'rfhen  must  the  process  be  completed?  How  long  does  a  process 
execute  on  the  processor?  How  many  turns  can  a  process  nave 
before  terminating? 

b.  Scheduling 

Scheduling  is  tne  ordering  of  processes  to 
run  on  processors  in  a  manner  that  realizes  the  policy.  It 
is  part  cf  the  mechanism  that  carries  out  the  policy. 

A  process  is  scneduled  by  sending  tne 
process  to  the  dispatching  port  in  the  form  of  a  messase 
object.  Once  in  tne  queue,  tne  process  waits  for  a  processor 
for  execution. 

c.  Dispatchins 

Dispatching  is  the  assignment  of  processes 
to  processors  in  the  order  in  which  the  processes  have   been 

scheduled . 

Tne  meeting  places  for  processors  and 
processes  srs  tne  Dispatcing  Ports  where  the  the  processes 
stand   in   line   waiting-  for  service   by   a   processor,   and 
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processors  go  wnen  tney  need  a  process  to  execute.  Wnenever 
a  processor  needs  a  process  to  execute,  it  simply  removes 
the  first  process  in  line  at  its  dispatc&ing  port  and  begins 
to  execute  it. 

2.   DiSEatcing  PfiUs  and  Program  Siru^ture 

We  nave  seen  tnat  tne  dispatcning  port  objects  are 
closely  related  to  tne  processor  object  and  process  object 
wnica  are  part  of  the  program  structure.  Tnis  relation  must 
be  well  controlled  in  order  to  prevent  perturbation  of  tne 
program  structure. 

For  example  tne  network  required  to  perform  process 
sc*ieduling  and  dispatching  is  complex.  To  iceep  trac^  of 
tnese  assignments  two  tnings  must  be  accomplisned .  First,  in 
eacti  processor  object  tnere  is  a  object  reference  for  tne 
processor's  dispatcning  port,  wnicn  means  tnat  eacn 
processor  has  only  one  dispatching  port.  This  information 
forces  a  processor  to  always  visit  tne  same  dispatcning 
port.  Second,  in  each  process  object  tnere  is  an  object 
reference  to  the  dispatching  port  the  process  is  allowed  to 
visit  and  thus,  a  process  can  visit  only  one  dispatcning 
port.  We  can  conclude,  therefore,  that  by  having  one 
dispatcing  port  per  processor  and  process  tne 
multiprocessing  task  of  the  432  can  be  accomplished  without 
major  effort  otner  tnan  assigning  tne  proper  policy  making 
parameters. 
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This  chapter  has  pressntel  the  characteristics  and 
advantages  of  tne  Intel  432  over  conventlnai 
microprocessors.  Although  this  chapter  is  lone  and  at  times 
detailed,  it  presents  the  requisite  information  necessary  to 
understand  the  results  observed  in  the  Benchmarx  Performance 
Chapter. 
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17.  MULTIPROCESSOR/MULTIPROCESS  BENCHMARK  PERFORr^ANCE 

In  general  tfte  Benchmarir  Performance  Test  was  conducted 
using  tne  BenchTiari  programs  generated  in  Applegate  [Ref. 
3J ♦  modified  as  required  to  execute  in  tne 
Multiprocessor/Multiprocess  environment.  Initially,  tne  test 
was  conducted  witn  only  one  processor  and  one  process  in  tne 
system  to  confirm  tne  results  reported  in  Applegate  IRef. 
3J .  Tnen,  using  tne  same  Bencnmara  Programs,  tne  test  was 
performed  with  two  processor/processes,  tnree 
processor/processes  and  finally  four  processor/processes  in 
tfte  system  to  determine  if  tne  432/57K  system  is  capable  of 
sustaining  incremental  performance  improvements  as 
processors  are  added  to  tne  system. 

A.   BENCHMARK  PERFORMANCE  TEST 

Kodres  [Ref.  12j  analyses  multiprocessor  systems  tnat 
uses  a  common  snared  memory.  Although  dependent  on  tne  type 
of  instructions  being  executed,  it  was  snown  tnat  if  tne 
programs  are  fetched  from  common  memory,  the  systems  bus 
becomes  a  bottleneck  witn  only  two  processors  in  tne  system. 
To  determine  if  the  INTEL  432/670  system  could  be  effective 
with  six  processors  as  reported  in  the  Intel  manual  [Ref. 
13]  ,  a  series  of  Eenchmarlr  performance  tests  were  conducted 
using  seven  programs  from  the  Computer  Family  Architecture 
Study   (CFS)   (Figures   4.1   -  4.4),   two   programs   from   a 
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perf  orrnance  comparison  conducted  by  the  University  of 
California  -  BerKeley  (Figure  4.5),  and  two  programs  tnat 
executed  instructions  at  opposite  ends  of  tfte  iAPX  432  bus 
activity  spectruTi  (Figure  4.6).  Ail  Bencnmaric  programs  were 
executed  witn  the  operating  system  configured  for  the 
default  service  period  (DF)  and  again  with  the  service 
period  set  to  infinite  period  count  (IF).  Each  figure 
depicting  performance  contains  the  name  of  the  Benchmaric 
program,  tne  number  of  iterations,  and  tne  number  of  seconds 
required  to  complete  the  execution  as  well  as  tne  curve 
showing  maximum  theoretical  efficiency,  observed  performance 
for  the  infinite  period  count  (IF),  and  default  (DF)  service 
periods.  Additionally,  calculated  efficiency  numbers 
associated  with  each  system  configuration  are  included  on 
the  right  side  of  the  graph  for  easy  reference. 

Each  program  was  executed  witn  tne  INTEL  432/67iJ  system 
configured  for  one  processor.  A  second  processor  was 
installed  and  two  processes  containing  identical  Bencnmars 
programs  were  timed  during  execution.  Processors  and 
processes  were  added  incrementially  up  to  and  including  four 
iAPX  432  General  Data  Processors  (GDP).  In  general  the  tests 
Show  that  tne  INTEL  432/67!^  system  was  still  performing  at 
approximately  ninety  percent  efficiency  with  four  processors 
in  the  system. 
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B.   RESULTS 

Since  Kodres  [Ref.  12J  prelictel  serious  bus  contention 
at  two  processors  and  the  observed  performance  is  still  at 
approximately  ninety  percent  witii  four  processors  in  the 
system,  additional  analysis  was  performed  using  a  Logic 
State  Analyzer  to  observe  systems  bus  activity  wnile 
executing  instructions  at  opposite  ends  of  tne  bus  activity 
spectrum.  Bencnmarfe  programs  were  designed  and  implemented 
tnat  execute  tne  MOVCH  instruction  to  represent  tne  nign  end 
of  bus  use  density  and  DIVORD  to  represent  the  low  end  of 
bus  activity. 

Shoop  [Ref.  14] ,  considering  a  system  bus  widtn  of 
sixteen  bits  and  a  nign  transfer  speed,  predicted  tnat  tne 
MOVCH  instruction  would  taice  10.4  microseconds  to  execute 
while  the  DI70RD  would  require  29.6  microseconds.  Usin?  the 
Logic  State  Analyzer  delay  function  and  triggering  on  a 
Known  address,  a  series  of  program  executions  were  performed 
to  generate  a  ^us  activity  snapshot  of  650  microseconds.  By 
counting  the  number  of  bus  access  cycles  and  tne  number  of 
execution  cycles,  the  relative  efficiency  of  the  Intel 
432/570  computer  system  was  calculated  for  one  tnrougn  S 
processors  usins  the  equation  derived  by  Kodres  [Ref.  12j  : 
Figure  4.7  depicts  tne  predicted  and  experimental  results 
for  the  MOVCH  and  DI70RD  instructions. 
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Re  =  (B  -t-  £)  /  (NB  +1)  wtiere  Re  =  Relative  efficiency 

B  =  Bus  activiiy  cycles 

E  =  Execution  Cycles 

I  =  System's  Bus  Iile 
Time 

N  =  Number  of  Processors 

To  determine  if  tne  lata  gatnered  during  tfte  Bus 
Snapsnot  period  was  representative  of  tne  BencnmarK 
performance  executions,  tne  instruction  execution  times  are 
compared  in  Table  4.1.  Tnere  is  a  small  difference  in 
execution  times  measured  by  tne  bus  activity  snapsnot  as 
opposed  to  timing  the  repeated  execution  of  tne  instruction. 
Since  tne  timing  is  accurate  to  tne  nearest  second,  tnis 
small  difference  can  be  attributed  to  measurement  error.  Tne 
larger  difference  between  Snoop  predicted  execution  times 
and  measured  execution  times  can  be  attributed  to  an  overly 
optimistic  prediction  by  Snoop. 

From  tne  calculations  displayed  in  Figure  4.7,  systems 
executing  instructions  consisting  of  MOVCH  would  begin  to 
saturate  tne  system's  bus  at  4.3  processors  wnile  DIVORD 
instructions  induce  tne  bottlenecK  at  7.7  processors.  Since 
tne  execution  time  of  DIVORD  is  greater  tnan  MOVCH,  it 
follows  tnat  ttie  predicted  bus  contention  should  be  less  for 
the  DIVORD  program  as  observed.  Since  tnese  instructions 
represent  bus  activity  at  opposite  ends  of  the  bus   activity 
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spectrum,    it   appears   t&at   tne   Intel's  design   of   six 
processors  per  system  is  an  appropriate  cnoice. 

C.   ANALYSIS 

Tne  explanation  for  tnis  performance  improvement  over 
t&at  observed  in  ot&er  Multiprocessor/Multiprocess  systems 
tnat  fetcn  programs  from  common  memory  Is  tne  INTEL  432/670 
system  nas  a  32  bit  system's  bus.  Ttie  32  bit  system's  bus 
nas  a  maximum  of  77  megabits  per  second  transfer  rate 
compared  to  about  12  megabits  per  second  for  a  typical  16 
bit  MULTIBUS  system's  bus.  Additionally,  tne  instruction 
formats  used  by  tne  lAPX  432  processors  are  designed  to 
reduce  the  number  of  bytes  transferred.  Finally,  by  usln^  a 
byte  addressable  boundary  ratner  tnan  a  word  boundary,  tne 
number  of  bytes  tftat  must  be  transferred  wnen  a  processor 
fetcties  instructions  is  reduced. 
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Figure  4.4   CFA  Bencftmaric  HASH  Performance. 
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Figure  4.7  Predected  and  Actual  Processing  Performance. 


Table  4.1   Instruction  Execution  Times  (Microseconds). 
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MOVCH 
DIVORD 


432/570 
OBSERVED 
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SHOOP 
PREDICTED 

12.4 

12.6 
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32.3 

32.1 

29.6 
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V.    CONCLUSIONS 

The  excessive  execution  overhead  resulting  from  tfte 
Intel  432  object  oriented  arcnitecture  nas  prevented  tne 
Intel  432  from  demonstrating  superiority  wnen  comparin?  its 
speed  of  execution  to  otner  microprocessors  in  a 
Uniprocessor  environment  (ie.,  one  processor  witn  its  ov»n 
memory  and  systems  bus).  For  example  wnen  compared  witn  tne 
Motorola  68ee0  and  the  INTEL  8086,  tne  lAPX  432  provided 
approximately  one-half  the  throughput  [PATTERSONJ  . 

BenchmarK  performance  depends  heavily  on  tne  instruction 
set  being  executed.  Since  individual  systems  use  unique 
methods  of  performing  certain  operations,  average  Bencnmars 
figures  could  be  misleading  if  the  system  was  to  be  designed 
for  a  specific  application.  For  example,  if  the  instruction 
set  required  was  predominately  Floating  Point  operations, 
the  INTEL  432  performance  should  be  superior  because  of  its 
efficient  Floating  Point  hardware. 

irfhen  comparing  a  computer's  ability  to  perform  in  a 
Multiprocessor  environment,  instruction  mix  is  still 
important  out  you  must  also  consider  the  bandwidth  of  the 
memory.  There  are  three  types  of  Multiprocessor 
architectures  that  effect  the  bandwidth  characteristics  of 
Multiprocessor  systems: 
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1.  Prosram  and  data  stored  in  ^loBal  memory  wiiere 
ail  processors  nave  equal  access. 

2.  Program  stored  in  a  local  memory  isolated  to 
access  only  by  ttie  parent  processor.  Data  would 
be  stored  in  global  memory. 

3.  Same   as   system  2  except  local  memories   are   also 

accessible   by  otner  processors  tnrou^n  a  Crossbar 
Switcn. 


The  Crossbar  Switcn  is  a  system  tnat  enables  tne  designer  to 
increase  tiie  number  of  system  buses  to  tne  point  wnere  tnere 
is  a  separate  patn  available  for  eacn  memory  unit.  Its 
obvious  advantage  is  to  eliminate  the  system  bus  contention 
wnen  operating  in  a  Multiprocessor/Multiprocess  environment. 
Since  many  real-time  applications  programs  reside  in  global 
memory,  tne  Bencnmart  test  were  conducted  in  tae  global 
memory  stored  program  environment.  Processing  power  of  a 
system  of  computers  sharinsr  a  common  systems  bus,  is 
measured  in  relative  efficiency  (see  Chapter  IV.  B.).  Eacn 
processor  must  be  able  to  process  the  program  steps  and  data 
witnout  interfering  with  eacn  other  by  saturating  tne  system 
bus  with  request  for  instruction  and  data  fetches. 

Analysis  of  the  INTEL  432/6745  system  Benchmark 
performance  test  show  that  the  relative  efficiency  of  the 
system  is  still  approximately  90  percent  with  four 
processors  in  tne  system.  Tne  effectively  maximum  number  of 
processors  is  confirmed  at  six.  This  is  in  sharp  contrast  to 
an  effectively  maximum  of  two  processors  for  tne  INTEL  8086 
operating  with  a  MULTIBQS  systems  bus  [KODRSSJ  .   Again  it  is 
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empnasized  tnat  tnese  performance  figures  are  Dased  on  a 
common  memory  stored  pro?ram  system. 

Altnougn  tnls  tnesis  was  not  concerned  with  transparent 
multiprocessing,  the  advantages  of  a  system  that  supports 
this  concept  was  evident.  During  Bencnmaric  program 
executions,  a  processor  was  prevented  from  being  initialized 
due  to  a  loose  piece  of  plastic  in  the  motherDoard  card  ed^e 
connector.  The  system  continued  to  function  automatically 
sequencing  the  extra  process  into  ttie  dispatcnins  queue.  The 
actual  failure  was  only  discovered  wnen  attempting  to 
determine  a  sudden  increase  in  execution  times. 

BenchmarJc  programs  for  this  project  were  written  in  the 
Department  of  Defense  programming  language  Ada.  Previously 
generated  code  was  found  to  be  self-documenting,  easy  to 
modify,  and  interfacing  problems  were  non-existant .  Although 
Ada  has  been  cited  as  a  complex  lan^uaee,  the  ease  with 
which  it  is  modified  combined  with  its  strong  typing 
characteristics,  and  readability  confirms  its  ability  to 
support  the  Software  Engineering  principles. 

While  tne  effectively  maximum  number  of  processors  for 
general  purpose  computing  in  the  INTEL  432/b70  system  is 
comfirmed  at  six  processors,  incorporating  tne  iAPX  432  into 
a  Crossbar  Switch  system  could  produce  a  system  capable  of 
supporting  up  to  54?  processors.  Its  direct  military 
application  to  tactical  systems  requiring  a  growtn  potential 
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is  exciting  particularly  waen  considering  tne  ability  of  tne 
iAPX  432  to  support  transparent  mul tiprocessin^r. 

Since  current  Navy  microcomputers  such  as  tne  A.N/A.TK-7 
cannot  be  expanded  beyond  four  processors  witnout  reauirin^ 
major  restructuring  of  tne  existing  software,  it  is 
recommended  that  a  follow  on  study  be  conducted  to  determine 
if  a  large  system  is  feasible  using  tne  iAPX  432  in  a 
Crossbar  Switcn  system. 
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APPENDIX  A 
ILll   ^32  VS  CONVINTIONAL  MAINFRAMES 

Ttiis  appendix  provides  a  comparison  of  tne  iAPX  432 
Arciii  tecture  and  the  Architecture  of  Conventional 
Mainframes. 


Feature  of  Archit. 
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Assembly  language 

oriented 
instruction  set 

No  support  at  all 


Software-transparent ' 
mul ti-processor, 
operation 

Oriented  toward  nign 
level  languages 


Object-based 
arcdi  tecture 
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APPENDIX   B 


PIN  DESCRIPTION 

This   appendix  provides  tfie  pin  description  of  me   iAPX 
432  general  daxa  processor. 

43201  Pin  Description, 

Processor  Pacjcet  Bus  Group. 

ACD15-ACD0   (Address/Controi/Data   lines,   Inputs,  hisn 

asserted ). 
PRO  (Processor  Packet  bus  Request , Input, nign  asserted). 
ICS  (Interconnect  Status,  Innut,  ni^n  asserted). 
Intra-GDP  Bus  Group. 

0115 — ai0   (Microinstruction  Bus   lines.   Outputs,   ni^n 
asserted) . 

IS6 IS0    (Intercnip  Status    lines.    Inputs,   nign 

asserted). 

System  Group 

FATAL/(?atal,    Output, low   asserted). 
ALARM/ (Alarm   signal , Input , low   asserted). 
INIT/dnitialization, Input, low   asserted) . 
CLH/(Clear, Input , low   asserted) 
Hardware   Error   Detection   Group 
Master    (Master , Input ,nigft   asserted). 
HERR/(Hardware    Error , Output , low  asserted). 

Cloci  Group 
CLKA,    CLKB    (Cloctt  A,    ClocK   3,    Inputs). 

Testing   Input 
RDROM/(Read   RDM, Input , low   asserted) 

Power  and   Ground   Connections. 

VCC    (4   pins  ). 

GND    (5   pins) 

VBB    (Internally   Generated^ 

N.C.    (No   Connection,    4  pins) 
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43202  Pin  Description 

Processor  Packet  Bus  Group 

PRO  (Processor  Pactet  request,   Tiiree-state  Output,  iiieh 

asserted) . 
ICS  (Interconnect  Status,  Input,  nigh  assertea). 
Bout  (Enable  Buffers  for  Output,  Output, nipn  asserted). 

Intra-GDP  Bus  Group. 

uI15-ul0  (Microinstruction  Bus    lines.    Inputs,    nign 

asserted) . 
IS6-IS0(Intercnip  Status  lines.  Outputs,  ai^n  asserted). 

System  Group 

PCLK/(Processor  ClocK,  Input,  low  asserted). 
CLR/(Clear, Input , low  asserted). 

Hardware  Error  Detection  Group. 

Master  (Master,   Input,  ni?n  assered;  25k  nomonal  pullup 

on-cftip) . 
HERR/(Hardware  Error,  Open  Drain  Output,  low  asserted). 

ClocS  Group 

CLKA.    CLKB    (Clocic  A,    ClocK  B,    Inputs). 

Power  and  Ground  Connections. 

7cc  (Power  Supply,  4  pins). 

GND  (Ground,  5  pins)  . 

N.C.  (No  Connection,  7  pins). 
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APPENDIX   C 

SAMPLE  PROGRAM  LISTING  WITH  SUBMIT  FILES 
This   appendix   contains   all   tue   necessary   files   to 
generate  Muitiprocessor/Multiprocesses  environment. 


CHARSUMSS 

—  CEARSl      pacica^e   specification 

—  Tnis  is  tfte  ADA  specification  pacKa^e  for  tne 

—  CFA  cnaracter  searcn  bencnmari. 

—  CHARSl 

pacica^e    SCHAR    is 
suDtype   subint   is   integer   ranse   1..25b; 
type    txtarray   is   array ( 1 . .256 )    of   cnaracter; 
arrayl , arrays    :    txtarray; 
procedure   SEAHCH(srcftien ,arglen    :    IN    subint; 

arrayl , arrays      :    IN    txtarray; 
loc    :    OUT   integer); 
end   SCHAR; 


CHARSKMBS 

—  CHARSl    package  Doiy 

—  Tae  following  package  contains  the  procedures  needed  to 

—  implement  tne  CFA  character  searcn  DencnmarK.  Procedure 

—  SEARCH  performs  tne  actual  searcn  as  desired  by  tne  CFA. 

—  CHARSl 

praema   environment( "ACS : TEXT  10. MLE" ,"INTI O.MS S", 

"schar.mse") ; 
wita    text   io,intio;    use    text_io tintio ,ascii ; 
pacKase    body   SCEAR   is 
procedure   SEARCH(srcnlen ,arglen    :    IN    subint; 

arrayl,array2      :    IN    txtarray; 

loc    :    OUT   integer;    is 
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i,J  :  integer; 
beein 
i  :=  i; 
J  :=  1? 
loc  :=  -i; 

wniie  i  <=  srcnien  loop 
if  arrayl(i)  =  array2(j)  tnen 
if  J+1  <=  arglen  tnen 
i  :=  i+i; 

else 
loc  :=  i-j; 
exit; 
end  if; 
else 
1  :=  i+i; 

end  if; 
end  loop; 
end  search; 
end  SCHAR; 


PRIMAIN^^SS 

package   US£R_PR0CESS_1   is 

procedure   I^AIN; 
end   USER   PROCESS    i; 


PR2MAIN.,^SS 


pacKa^e  aSER_PR0CESS_2  is 

procedure  MAIN; 
end  aSER  PROCESS  2; 


PR3MAIN.^SS 


pacKage  USER_PR0CESS_3  is 

procedure  MAIN; 
end  JSER  PROCESS  3; 


PEidAINiMS.S 


package  USER_PR0CESS_4:  is 

procedure  MAIN; 
end  USER  PROCESS  4; 
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PRIMAIN.MBS 
— CHARSl   driver  routine 


pragma  environment( "aCS:TEXTIO.MLE" , " INTIO.MSE" , "SCHAR.MSS" , 

"PRIMAIN.MSE"); 
wit&  text  iOflntio, schar;  use  text  io , iniio.scnar ,ascii ; 


—  Tiding  also  includes  time  for  procedure 

—  invocation 
3  May  1983 

pac!ca?e    body  USER_PR0CESS_1    is 
procedure  l^AIN   is 
i  ,loc ,srcn_lengtn, 5rcn_arg,timer_loop    :   integer; 

beein 


—  initialization 

arrayl  :=(M,o,n,dfa,y,,,    »J,u,n, 
ef7,t,tit»»    ,i,y,r,D, 

otners  =>  '  '); 
array2  :=  ( 'd' , 'a' , 'y' .otners  =>  '  '); 


srcn_lenffth 
srcn_arg 
timer  loot) 


=   22; 

=   3; 
.___,,  ^_      =  i000iJ0; 
put   20(*'   Start    of   Search. .  .1"  ) ; 
putTEEL) 
put(3SL) 
put (BEL) 
put(£EI) 
put(BEL) 
for   i   in   1..    timer_loop   loop 

SEARCH(  s rcn_l eng tn 7s rcn_arg, arrayl , array 2,  loc)  ,' 
end    loop; 

put   20("end    tfte    search l"); 

nutlBEL); 
put (BEL); 
put (BEL); 
put(EEL); 
put(BEL); 
end  main; 
end  OSER  PROCESS  i; 
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— CHARSl      driver    routine 


pragma    environment( "ACS :T5XTI0.MLE" ,"lNTIO.MSE" ,"sCHAR.MSE" , 

"PR2MAIN.MSE"); 
witu   text_io,intio,5char;    use   text_io, intio , scaar  ,ascii ; 


—  Timing  also   includes    time   for   procedure 

invocation. 
3   nay    1983 

pacfcaffe    body   USER_PR0CESS_2   is 
procedure   MAIN   is 
i  »loc  ,srcti_lengtn  ,src[i_arg  , time r_ loop:  integer; 

oegin 


—  initialization 


arrayl    :=(M,o,n,l,a,y,,,         ,J»u,n, 
'e\'7','t','n',',','    '/I', '9', '7', '5', 

otners    =>    '    ')J 
array2    :=    ( 'd' , 'a' , 'y '  ,ottiers    =>    '    '); 


srcn_lenfftn 

5rcn_arg 

timer_loop 


=  22; 

=  3; 

=  100000; 
put  20 ("  Start  of  Searcn. . .2" )  ; 
DutlEEL); 
put(BSL); 

put (EEL); 

put (BEL); 

put(EEL); 

for   i   in   1..    timer_loop   loop 

SEARCH(  srcn_leTigtn  ,5rcn_arg  .array  1 , array 2,  loc  ) ; 

end   loop; 

put    20("end    tne    searcn 2"); 

putlBEL); 

put (BEL); 

put(BEL); 

put (BEL); 

put(BEL); 
end  main; 
ind  aSER  PROCESS  2; 
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PR3MAIN.MBS 
— CHARSl     driver   routine 


pragma  environmen  t(  "ACSrTEXTIO.MLE" /'iNTIO.MSE",  "sCHAR.r^SE"  , 

"PR3MAIN.MSE"); 
tfitn  text_lo ,intio, scnar;  use  text_io ,intio ,scnar .ascii ; 


—  Tining  also  includes  time  for  procedure 

—  invocation. 
3  May  1983 

pacsa^e    body  USER_PR0CESS_3    is 
procedure  MAIN   is 
i  ,loc  ,src&_lengtft ,srch_arg,timer_loop    :    integer; 

beffin 


—  initialization 

arrayl    :=(M,o,n,d,a,y,,,         ,J,u,n, 
'e','7','t','n','.','    '/l'.'9'/7'.'5'.    , 

others   =>    '      )  ; 
array2    :=    ( 'd' , 'a', 'y' , others   =>    '    ')» 
srcn_leneth    :=   22; 
srcn  arg  :=   3; 

timer__loop      :=    100000; 

put^SaC*   Start    of   Search  ..  .3"  ); 

putTBEI); 

put(BEL  ); 

put(BEL); 

put (BEL  ); 

put(B£L); 

for  i  in  1..  timer  loop  loop 

SEARCH( srcn_lengtn7srcn_arg,arrayl tarray2,loc) ; 

end  loop; 

put  20("end  the  search 3"); 

putlBEL) 

put(ESL) 

put(EEL) 

put(BEL ) 

put (BEL) 
end  main; 
end  aSER  PROCESS  3; 
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PR4MAINiMBS 
— CHARSl      driver    routine 


praffma   environment( "ACS:TEXTI0.MLS" ,"lNTIO.MSE" , "SCHAR.MSE" ♦ 

"PR4MAIN.MSE"); 
witn   text_io ,intio, scnar;   use   tezt_io, mtio, scnar.ascii ; 


Timing  also   includes    tine   for  procedure 
invoca  ti  on. 
3  May   1983 


pacfcage   body  0SSR_PR0CESS_4   is 
procedure   MAIN   is 
i  ♦loc,srcti_lengtn ,  srcn_arg  ,timer_loop 
forever    :    boolean    :=true» 
answer    :   character; 

begin 


integer; 


wtiile   forever  loop 
—  initialization 


M    ,    o,n,d,aty,,,         f.*^,*   ^.»    ^    ♦ 
e,7,t,ft,,,         ,1,9,7,5, 

otners   =>    '    '); 


arrays    :=    ( 'd' , 'a' , 'y' , otners   =>    '    '); 


srcii_lenetn 
srcn_arg 
timer   Iootd 


=  22; 

=  3; 
_   ^   =  100000; 
put~20("  Start  of  Searcn  . .  .4"  ) ; 
putlBEL); 
put(BEL); 
put (BEL); 
put(BELJ; 
put(BEL); 

for  i  in  1..  timer_loop  loop 

SEARCH ( srcn_leagtn,srcn_arg,arrayl,array2,ioc ) ; 
end  loo^; 

-put_20(  end  tlie  search 4"); 

put (BEL); 
put(BEL); 
put(BEL); 
put (BEL); 
put(3EL); 
forever  :=  false; 


end  loop; 
end  main; 
end  USER  PROCESS  4; 
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DrPSERPl^MBS 

Pragma  environmen j( "ACS rBPM.MLE" ,"aCS  rVlUSRP.MLl", 

PRIMAIN  .MSB",  'PR2MAIN.MSE"  ,"PR3MAIN.MSE"  ,"PR4[^AIN  .MSE"  )  ; 
with  Process_Def ini tions,  iMAX_Def ini tlons, 

Basic_Process_manaffement » 
with  0ser_Process_l,0ser_Process_2,User_Process_3, 

User_Proces5_'4:; 
pac*cage    body  Oser_Processes   is 

—  Function: 

Tnis  Tjodule   instantiates   tne  user   processes   and 

—  provides  an  initialize  procedure  wnicn  completes  the 
initialization  of  each  user  process. 

For  each  user  process,   there  is   an  instance   of 

—  iMAX_Definitions.proc9iure_val  which  contains  the 
process'  initial  procedure.    To  minimize  tne  size  of 

—  this  pactcage,  the  initial  procedure  here  simply  calls 
tne  actual  initial  procedure  wnich  is  found  in 
another  module.   For  each  process,   there  is  also  an 

—  instantiation  of  Process_Def ini tions. Process_Instance 

—  which  specifies  the  process  id,  the  procedure_val 
just  mentioned,  and  tne  process'  stacjf  SRO  and  object 
table  sizes. 

Finally,   tne   initialize  procedure  provided  by   this 

—  module  simply  calls  the 

—  Complete__process__initializat ion  procedure 

in  eacn  instantiation  of 

—  Process_Defini  tions. Process_Ins tan ce. 

procedure  prlmain; 
procedure  pr2main; 
procedure  prSmain; 
procedure  pr4(nain» 


—  SPECIFICATIONS  FOR  USER  PROCESS  1  — 


pacfcage  UPROCl  is  new  Process_Def ini tions .Process_Instance 
(Process_Startup  =>  prlmain, 
SRO_size  =>  4000); 
—  service_period  => 

basic_process_fnanagement .  inf  ini  te_period_count ) » 
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—  SPECIFICATIONS  FOR  USER  PROCESS  2  — 


pacica^e   IJPR0C2   is   new  Process_Dei'ini  tions  .Process_Instance 
(Process_Startup  =>   prSrnain, 
SR0_5ize   =>   4000); 
—  servlcs_perio1  => 

basic_process_management .Infini te_period_count ) ; 


—   SPECIFICATIONS    FOR   USER  PROCESS    3   — 


package   UPR0C3   is   new   Process_Def initions .Process_Instance 
(Process   Startup  =>  prSmain, 
SR0_si2e   =>   4000); 
—  service^period  => 

basic_process_fnanagement .  infini  te_periocl_count ) » 


—  SPECIFICATIONS  FOR  USER  PROCESS  4  — 


package  0PR0C4  is  new  Process_Defini tions .Process^Instance 
( Process_Startup  =>  pr4main, 
SRO_size  =>  4000) ; 
—  service_period  => 

Basic  Process  Management . Infinite  Period  count); 


—  BODIES  FOR  USER  PROCESS  1  — 


procedure   prlnnain   is 
Begin 

Use r_Process_i. main; 
end  prlmain; 


—  BODIES  FOR  USER  PROCESS  Z    — 


procedure  prSnain  is 
be^in 

User_Process_2.main; 
end  pr2main; 
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—  BODIES  FOR  USER  PROCESS  3  — 


procslure  prSmain  Is 
begin 

Ussr_Process_3.main; 
end  prSmain; 


—  BODIES  FOR  USER  PROCESS  4  — 


procedure  pr4:main  is 
begin 

Use r_Process_4. main; 

end  pr-imain; 


—  PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES  — 

procedure  Initialize 

is 
beffin 

UPROCl.Co7iplete_process_initlaiization; 

—  UPROC2.Complete~process_ini tialization; 

—  0PR0C3.Compl?le_process_initialization; 

—  UPROC4.Co7iplete_proces5_iniiialization; 
end    Initialize; 

end   Jser   Processes; 
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DFPSERPZ^MES 

Pragma    environment( "ACS : BPM.MLE" ,"aCS : VlUSRP.MLl" , 

"PRlMAlN.MSE","PR2MAIN.MSE","PR3:iAIN.MSE","PR4YAIN.^SE"); 
wlta  Proces5_Definitions»  lMAX_Def initions , 

Basic   Process_rnandgerTient ; 
with   User_Process_l ,Qser_Process_2,User_Frocess_5 , 

U5er_Process_4; 
pacfea^e    body  LIser_Proce5ses    is 

—  Function: 

Tnis   module   instantiates   tne  user   processes   and 

—  provides  an  initialize  procedure  wnicn  completes  tne 
initialization  or  eacn  user  process. 

For  each  user  process,   tnere  is   an   Instance   of 

—  iMAX_Definitlons.procedure_val  wnicn  contains  the 
process'  initial  procedure.  To  minimize  tne  size  of 
this  paclcage,  the  initial  procedure  here  simply  calls 
the  actual   initial   procedure  which   is   found   in 

—  another  module.  For  eacn  process,  there  is  also  an 
instantiation  of  Process_Def initions .Process_Instance 

—  which  specifies  the  process  id,  tne  procedure_val 
just  mentioned,  and  tne  process'  stact  SRO  ana  object 
table  sizes. 

Finally,   tne   initialize  procedure  provided  by   tnis 
module  simply  calls  the 

—  Complete_process_ini tialization  procedure  in  each 
instantiation  of  Process_Def initions .Frocess_Instance 

procedure  prlmainj 
procedure  prSmain? 
procedure  pr?main; 
procedure  pr4main; 


—  SPECIFICATIONS  FOR  USER  PROCESS  1  — 


package  UPROCl  is  new  Process_Eef initions. Process_Instance 
( Process_S tartuD  =>  prlmain, 
SRO_size  =>  40045); 
•  service_period  => 

basic_process_management .inf ini te_period_count ) > 
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SPECIFICATIONS  FOR  USER  PROCESS  2  — 


pacSca^e   UPR0C2   is   new   Proce5S_Def  ini  tions  .Process_IiistaRC9 

(Process   Startup  =>   pr2main, 
SRO_size   =>   406J0); 
—  servlce_periO'i  => 

basic_process_management .  inf  inite_perio(i_count )  > 


SPECIFICATIONS    FOR   USER  PROCESS    3   — 


package   UPR0C3   is   new  Process_Defini tions .Process_Instance 
( Process_Startup  =>   prSmain, 
SR0_si2e   =>   4000) ; 
—   service_period  => 

t)asic_process_management .  infinlte__perio(i_count ) ; 


—  SPECIFICATIONS  FOR  USER  PROCESS  4  — 


pacKaee  UPR0C4  is  new  Process_Definitions .Process_Ins tance 
(Process  Startup  =>  pr4main, 
SR0_size  =>  4000); 
—  service_period  => 

Basic_Process_Management . Inf ini  te_?eriod_count  ) ; 


—  BODIES  FOR  USER  PROCESS  1  — 


procedure  prlmain  is 
begin 

dser_Process_l.MAIN; 
end  prlmain; 


—  BODIES  FOR  USER  PROCESS  2  — 


procedure  pr2main  is 
begin 

User_Process_2.maini 
end  pr2main; 
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—  BODIES  FOR  USER  PROCESS  3  — 


procedure  prSmain  is 
beffin 

User_Process_3.main; 
end  pr3main; 


—  BODIES  FOR  USER  PROCESS  4  — 


procedure  pr4main  Is 
begin 

Use  r_Process_4:.  main; 
end  pr4main» 


—  PROCEDURE  TO  INITIALIZE  kll   USSR  PROCESSES  — 


procedure  Initialize 

is 

be?in 


UPROCl.Co'nplete_process_initiaii2ation; 
UPROC2.Complete~pro<^ess_initializdtion; 

—  0PR0C3.Co'nplete_prcces5_initialization; 

—  UPROC4.Complete_process_lnitiaii2ation; 
end  Initialize; 


end  User  Processes; 
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DFPSERPS^^IBS 

Praffma   environment( "aCS:BPM.MLE" ,"aCS rVlUSRP.MLl"  , 

''PR1MAIN.MSE'',"PR2MAIN.MSE","PR3MAIN.MSE"/'PR4MAIN.MSE")  ; 
witn  Process_Def inl tions,    iMAX_Def ini tions, 

Pasic_Process_rpanafferrent » 
with   Oser_Process_l ,0ser_Proces5_2,User_Process_3 , 

User_Proress_4; 
package    body  User^Processes   is 

—  Function: 

—  This   module   instantiates   tne  user   processes   and 
provides  an  initialize  procedure  wnicft  completes   tne 

—  initialization  of  eacn  user  process. 

For   eacn  user  process,   tnere  is   an  instance   of 

—  iMAX_Def Initions .procedure_val    which   contains   the 
process'  initial  procedure.    To  minimize  the  size  of 

—  this  pacltape,  ttie  initial  procedure  here  simply  calls 
the  actual   initial   procedure  wnicn   is   found   in 

—  another  module.    For  each  process,   there  is  also  an 
instantiation  of  Process__Def  ini  tions.  Proces5_Instance 

—  wnicn   specifies  tne  process   id,   tne   procedure_val 

—  Just  mentioned,  and  tiie  process'  stacs  SRO  and  object 
table  sizes. 

—  Finally,   tne   initialize  procedure  provided  by   tnis 
module  simply  calls  tne 

—  Complete_process_ini tiaii zation   procedure   in   eacn 
instantiation  of  Process_Def initions .Process_Instance 

procedure  prlmain; 
procedure  prSmain; 
procedure  pr3main» 
procedure  pr4main» 


—  SPECIFICATIONS  FOR  USER  PROCESS  1  — 


pacisa^e  UPROCl  is  new  Process_Def  ini  tions  .Process_Instance 
(Process_S tartup  =>  prlmain, 
SRO_size  =>  4000); 
—  service_period  => 

basic_process_management .  inf  ini  te_period_count ) »' 
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—   SPECIFICATIONS    FOR   USER   PROCESS    2    — 


package   UPR0C2   is   new   Process_Def initions .Process^Ins tance 

(Process   Startup  =>  pr2maln, 
SRO_slze  =>  40i50); 
—  service_perlod   => 

baslc_proces5_maiiagement .  inf  inite__perioci_count )  > 


—  SPECIFICATIONS  FOR  USER  PROCESS  3  — 


pacicaffe   UPR0C3   is   new   Process_Def initions.Process^Instance 
(Process  Startup  =>   pr3main, 
SR0_si2e   =>   4000) ; 
—  service_period  => 

Dasic_proces5_mana^ernen  t .  infini  te_periO'l_count ) ; 


—  SPECIFICATIONS  FOR  USER  PROCESS  4  — 


pacKage  UPR0C4  is  new  Process_Def initions .Process_Instance 
( Process_Startup  =>  pr4main, 
SRO_size  =>  4000); 
—  service_period  => 

Basic  Process  Management . Infini te  Period  count); 


—  BODIES  FOR  USER  PROCESS  1  — 


procedure  prlmain  is 

begin 

Use r_Process_l. main; 
end  prlmain; 


BODIES  FOR  USER  PROCESS  2  — 


procedure  pr2main  is 
begin 

User_Process_2.main; 
end  pr2main; 
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—  BODIES  FOR  USER  PROCESS  3  — 


procedure  prSmain  is 
tesin 

User_Process_3.mainf 
end  pr3main; 


—  BODIES  FOR  USER  PROCESS  4  -- 


procedure  pr^maln  is 
begin 

User_Process_4.main; 
end  pr4main; 


—  PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES  — 

procedure  Initialize 

is 

beein 

UPROCl.Co'npiete_process_initiaiization; 

0PR0C2.Complete_process_initiali2ation; 

UPROC 3. Complete  proces5_iniiializalion; 
—  UPROC4.Co'nplete~proce5S_initidiization; 
end  Initialize; 

end  User  Processes; 
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DFPSERP^i^BS 

Praerna   environrnen.i;(  "ACS  :BPM.!^LE"  ,"acS  : VlUSRP.MLl", 

"PR1MAIN.^SE",'PR2MAIN.MSE","PR3MAIN.MSE","PR4MAIN.MSE"); 
wit&  Process_Definitions,  iMAX_Def ini tions, 

Basic_?rocess_managernent ; 
with  User_Process_l ,User_Process_2 ,User_Process_5 , 

User_Process_4 j 
package  body  User_Processes  is 

—  Punction: 

Tnis  module  instantiates  tne  user  processes  and 
provides  an  initialize  procedure  wnicn  completes  tne 
initialization  of  eacn  user  process. 

For  eacn  user  process,  tnere  is  an  Instance  or 
i^'AX_Definitions.procedure_val  wnicn  contains  tne 
process'  initial  procedure.  To  iDinimize  tne  size  of 
tnis  pacfca^e,  tne  initial  procedure  nere  simply  calls 
tae  actual   initial   procedure  wi^icn   is  found   ir. 

—  another  module.  For  eacn  process,  tnere  is  also  an 
instantiation  of  Process_Def ini tions.Process_Instance 

—  which  specifies  tne  process   id,   the  prorelure_val 

—  just  mentioned,  and  tne  process'  stacK  SRO  and  otject 
table  sizes. 

Finally,   the  initialize  procedure  proviaed  by  tnis 

—  module  simply  calls  tne 
Complete_process_ini tiali zatlon  procecure  in  eacn 
instantiation  of  Process_Def ini tions .Process_Instdnce 

procedure  prlmain; 
procedure  pr2main» 
procedure  pr3main; 
procedure  Br4main» 


—  SPECIFICATIONS  FOR  aSER  PROCESS  1  — 


pacKaffe  UPROCl  is  new  Process_Def initions .Proces5_Instance 
( Process_S tartup  =>  prlmain, 
SRO_size  =>  4fc500) ; 
•  service__period  => 

basic_proces5_managemen t . inf inite_perioa_count ) ; 
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—  SPECIFICATIONS  FOR  OSER  PROCESS  2  — 


pacffase  UPR0C2  Is  new  Process_Def ini tions.Process_Instance 
(Process_Startup  =>  pr2main, 
SR0_si2e  =>  4000); 
—  servlce_perlod  => 

Da  sic_process_inanagement  .inf  ini  te_perlocl_count )  ? 


—  SPECIFICATIONS  FOR  USER  PROCESS  3  — 


pacKaffe  UPR0C3  is  new  Process_Definitions .Process_In5tance 
(Process_Startup  =>  pr3nain, 
SRO_size  =>  4:000) ; 
—  service_perlol  => 

Ba5ic_j)roces5_management  .infinite_periO(i_  count); 
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—  SPECIFICATIONS  FOR  USER  PROCESS  4  — 


pacisaffe  QPR0C4:  is  new  Process_Deflrxi tions  .Process_Instance 
(Process  Startup  =>  pr4main, 
SRO_size  =>  4000); 
—  5ervice_period  => 

Basic_Process_Management .  Inf  inite_Perlo(i_count ) ; 


—  BODIES  FOR  USER  PROCESS  1  — 


procedure  prlmain  is 
beein 

aser_Process_l.MAIN; 
end  prlmaini 


—  BODIES  FOR  USER  PROCESS  2  — 


procedure  prHmain  is 
be^in 

User_Process_2.main; 
end  pr2main; 


—  BODIES  FOR  USSR  PROCESS  3  — 


procedure  pr3main  is 
teffin 

User_Process_3.main» 

end  pr3main; 


—  BODIES  FOR  USER  PROCESS  4  — 


procedure  pr4main  is 
begin 

User_Proces5_4.main; 
end  pr4maln; 
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—  PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES  — 

procedure  Initialize 

is 

beffin 

OPROCl.Co.Tiplete^process^initiaiization; 

aPROC 2. Complete "process "initialization; 

aPROC3.Co!nDlete"proces5_initialization; 

UPROC4.Complete_process_lnitializailon» 
end  Initialize; 

end  Qser  Processes; 
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DFLINKl^LKD 
»  instruction  test  program 

lint  ACS tminmai.eod 
ACS  nextio.mlo 

intio  .mso 

scnar  ,mso 

schar.mbo 

prlmain.mso 

prSmain.mso 

prSmain.mso 

pr4main.mso 
prlmain.mbo 
prSmain.rnDo 
pr3main.nibo 
pr4main.mt)0 
dfpserpl .mbo 

psors .mbo 

free{30  in  directory) 

output   dfcharl.eod 

objectmap 


DFIINK2.LKD 


;  instruction  test  program 

llnfe  ACS rminmax.eod 

ACS :textio.mlo 

intio .mso 

schar .mso 

scftar .mbo 

prlmain.mso 

pr2main.mso 

prSmain.mso 

pr4main.mso 

prlmain .mbo 

pr2main.mbo 

prSmain.mbo 

pr4main.mbo 

df pserp2.mbo 

psors  ,mbo 

freeCse  in  directory) 

output    dfchar2.eod 

objectmap 
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I  instruction  test  program 

linK   ACS tminmax.sod 

ACS  ttextio .mlo 

intio.mso 

schar .mso 

scnar.mbo 

primain.mso 

pr2main.rnso 

pr3Tiain.mso 
pr4main.mso 
prlmain.mbo 
prSmain  ,mbo 
prSmain.mbo 
pr4r"ain.mfco 
df pserpS.mbo 
psors  .mbo 

free(30  in  directory) 

output    dfcnarS.eod 

objectmap 


;  instruction  test  program 

lint  ACS rminmax.eod 

ACS  ttextio ,mio 

intio.mso 

scflar  .mso 

scnar.mbo 

primain.mso 

pr2main.mso 

pr3main.mso 

pr4main.mso 

prlmain.mbo 

prSmain .mbo 

pr3main.mbo 

pr4main.mbo 

If pserp4.mbo 

psors .mbo 

free(30  in  directory) 

output  dfcnar4.eod 

objectmap 
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INFPSERPl^^ES 

Pragma   environrrientC  "ACS  rSPM.MLS" /'ACS  :  VlUSRP.MLl"  , 

"prima  IN  .y!SS",  "PR2MAIN.MSE"  /'PR3MAIN.MSE"  ,  "PR4r^Al  N  .  r^S  E"  )  ; 
witfi   Process_Definitions,    iMAX_Def  Ini  tions, 

Basic   Process_mandffement » 
witft   U5er_Process_l ,Qser_Proce5S_2,User_Froc9S5_3, 

User_Proress_4; 
pacKage   body  User_Proces5es    is 

—  Function: 

—  Tnis   module   instantiates   the  user   processes   and 

—  provides   an  initialize  procedure  wnicn  completes  tne 

—  initialization  of  eacn  user  urocess. 


—  Finally,   the   initialize  procedure  provided  by   this 

—  module  simply  calls  tne 

—  Complete_process_ini tialization   procedure   in   each 

—  instantiation  of  Process_Defini tions .?rocess_Ins tance 

procedure  prliiain; 

procedure  prSmainJ 

procedure  pr3'nain» 

procedure  pr4main; 


—  SPECIFICATIONS  FOR  USER  PROCESS  1  — 


pacicage   UPROCl    is    new   Process_Defini  tions. Process_Instan''e 
(Process_S tartup   =>   prlmain, 
SRO_size   =>   4000, 
service_period   => 

ba  5ic_process_mdndgement . inf ini  te_period_count ) ? 
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—  SPECinCATIONS  FOR  USER  PROCESS  2  — 


paclcage  UPR0C2  is  new  Process_Def  ini  tlons  .Process_Ins  tance 
(Process_Startup  =>  pr2main, 
SR0__5lze  =>  40i50, 
service_period  => 

baslc_process_nanagement .  inf  iniie_periocl_count; ) » 


—  SPECIFICATIONS  FOR  USER  PROCESS  3  — 


pacfease  UPR0C3  is  new  Process_Definiiions .Process_Instance 
(Process_S ta rtup  =>  prSmain, 
SRO_size  =>  4000, 
service_period  => 

basic_process_rnanagement  .inflnile_periO(i_co\:nt ); 


—  SPECIFICATIONS  FOR  USER  PROCESS  4  — 


pacKa^e  UPR0C4  is  new  Proce5S_Def inition5.Proces5_Ins tance 
(Process_Startup  =>  pr4main, 
SRO_sizp  =>  4000, 
service_period  => 

Basic_Process_^'anagement .  Inf  ini  ie_Perio4_count ) ; 


—  BODIES  FOR  USER  PROCESS  1  — 


procedure  prlmain  is 
begin 

User_Process_l.MAIN; 
end  prlmain; 


—  BODIES  FOR  USSR  PROCESS  2  — 


procedure  pr2main  is 
beffin 

User_Process_2.main; 
end  pr2main; 
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—  BODIES  FOR  USER  PROCESS  3  — 


procslure  prSmain  is 

begin 

US2r_Process_3.main; 
end  prSmain; 


—  BODIES  FOR  USER  PROCESS  4  — 


procedure  pr^.Tiain  is 
be?in 

User_Process_4.main; 
end  pr4main; 


—  PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES  — 

procedure  Initialize 

is 

begin 

UPROCl  .CorT'plete_process_initialization; 

—  UPROCH.Co-npiete_proces5_ini  tialization; 

—  UPROC3.Comple te~p^oc^ss_initlalization; 

—  UPROC4.Complete_process_ini tialization; 
end  Initialize; 

end  User  Processes; 
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INFPSERP2j.MBS 

Pragma  environmen,-5(  "ACS  :BP^^.^^LE"  ."ACS  :  VlUSRP.r^Ll"  , 

PRIMAIN.MSE",  'PRliMAIN.MSl!;","PR3MAlN.MSE","?R4MAlN.>1S]!:"  )  ,* 
with  Process_Defini tions,  iMAX_Def initions , 

Basic_Process_!T'artagemert  ? 
witn  User_PrDcess_l ♦User_Process_2,User_Process_3, 

Oser_Process_4; 
pacicaffe    body  User_Processes   is 

—  Function: 

—  Tnis  nodule   instantiates   the  user  processes   and 

—  provides  an  initialize  procedure  wnicn  completes  tne 

—  initialization  of  eacn  user  process. 

—  For  eacn  user  process,   tnere  is   an  instance  of 

—  iMAX_Definiti ons.procedure_val   wnich  contains   tne 

—  process'  initial  procedure.   To  minimize  tne  size  of 

—  tnis  package,  the  initial  procedure  nere  simply  calls 
~  tfte  actual   initial   procedure  wnicft  is   found   in 

—  anotner  module.   For  eacn  process,   tnere  is  also  an 

—  instantiation  of  Process_Def initions .Process_Instanre 

—  wnicn  specifies   tne  process  id,   tne  procedure_val 

—  Just  mentioned,  and  tne  process'  stacic  SRO  ana  otject 

—  table  sizes. 

—  Finally,   tne   initialize  procedure  provided  by   tnis 

—  module  simply  calls  the 

—  Complete_process_ini tialization   procedure   in   each 

—  instantiation  of  Process_Deflni tions. Process_Instance 

procedure  primain; 
procedure  pr2main; 
procedure  prSmain; 
procedure  pr4main; 


—  SPECIFICATIONS  FOR  USER  PROCESS  1  — 


pacKase   UPROCl    is    new   Process_Def initions .Process_Instdnce 
( Process_S tartup   =>   primain, 
SRO_size    =>   4eiJe, 
service_period   => 

ba  sic_process_management . inf lnite_period_count ) ; 
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—    SPECIFICATIONS    JTOR    USER    PROCESS    2    — 


pacira^e   UPR0C2   is   new  Process_Def  inltions  .Process_Ir.stance 

(Process    Startup  =>   pr2main, 
SRO_size   =>   400^3, 
service_perio(i  => 

basic_process_management . inf ini  te_period_count ) » 


—  SPECIFICATIONS  FOR  USER  PROCESS  3  — 


pacKase  _[JPR0C3   is   new  Process_ref  initions  .Proce5S_Instance 
(Process    Startup  =>    pr3main7 
SRO__size   =>   4:000, 
ssrvice_perioi   => 

Dasic_process_managerTient  .inf  lnite_perioci_count )  ; 


—    SPECIFICATIONS    FOR    USER   PROCESS    4   — 


pacfca^e   UPR0C4   is   new   ?rocess_Cenni  tions  .Process_Ins  tance 
(Process_Startup  =>   pr4nain7 
SR0_si2e   =>   4000, 
service__periol  => 

3asic_Process_*^anagefTient  .Infinite_PeriO'l_count  ); 


—    BODIES    FOR    USER    PROCESS    1    — 


procedure   prlTiain    is 

Deein 

Use r_Frocess_l. main; 
end  prlmain; 


—  BODIES  FOR  USER  PROCESS  2  — 


procedure  pr2Tiain  is 
begin 

User__Process_2.main; 
end  pr2main; 
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—    BODIES    FOxR    USER   PROCESS    3    — 


procedure   pr3main   is 
be^in 

dser_Process_3.main; 
end  prSmain; 


—  BODIES  FOR  USER  PROCESS  4  — 


procedure  pr4main  is 
beffin 

U5er_Process_4.main; 
end  pr4main; 


—  PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES  — 

procedure  Initialize 

is 

begin 

UPROCl.CoTipiete_process_initiaiization; 

0PR0C2.Co!nplete_process_initiaiization; 

—  UPR0C3.CcTipiete_-Drocess_initiaiization; 

—  UPR0C4.Co:npiPte_pro':ess_initialization; 
end    Initialize; 

end  User  Processes; 
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Pragma  envlronment(  "ACS  tBP!^  .MLE"  ,'\\CS  :  ViaSRP.MLl"  , 

'PRIMAIN.MSE'*,  '■PRHMAIN.MSE","PR3MAIN.MSE","PR4MAIN  .."^SE")  ; 
with  Process_Definitions,  lMAX_Def initions, 

Basic   Process   rnanageirent ; 
witQ   lIser_Process_l  ,irser_Process_2,User_Proce5S_3, 

User_Process_4; 
pacKaee    Dody  User_Processes    Is 

—  Function: 

—  This  Tioduie  instantiates   tfte  user  processes  and 

—  provides  an  initialize  procedure  wnicn  corrpietes  tne 

—  initialization  of  eacn  user  process. 

—  For  eacn  user  process,   tnere  is  an  instance   of 

—  iMAX_Def ini ti ons. procelure_val  wnich   contains   tne 

—  process'  initial  procedure.    To  minimize  tne  size  of 

—  tnis  pacKage,  tne  initial  procedure  nere  simply  calls 
the  actual  initial  procedure  wnicn  is  found  in 
another  Tiodule.   For  eacn  process,   tnere  is  also  an 

—  instantiation  of  Process_Def initions .Prccess_Instance 

—  wnicn  specifies   the  process  id,   the   procedure_vai 

—  Just  Tentioned,  and  the  process'  stacs  SRO  and  oDject 
taDle  sizes. 

—  Finally,   the   initialize  procedure  provided  Dy   this 

—  module  simply  calls  tne 

—  Complete_process_initialization  procedure  in  each 
instantiation  of  Process_Def ini tions .Process_Instance 

procedure  prlrain; 
procedure  pr^main? 
procedure  prSTiain; 
procedure  pr4main; 


—  SPECIFICATIONS  FOR  QSER  PROCESS  1  — 

pacia^e   IJPFOCl    is    new   Process_Cef  ini  tions. Process_Instance 
(Prccess_S tartup  =>   prlmain, 
SRO_size    =>   40i)0, 
5ervice_period   => 

Dasic_process_management .infinite_period_count); 
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—  SPECIFICATIONS  FOR  USER  PROCESS  2  — 


pacicage   UPR0C2   is   new   Process_Defini  tions  .Process_Ins  tance 
( Process_Sia rtup  =>   prSmain, 
SRO_size  =>   4000, 
service_period   => 

Daslc_proce5s_mana«ement .  inl'ini  ie_period_count ) ; 


SPECIFICATIONS  FOR  USER  PROCESS  3  — 


package  UPR0C3  is  new  Proce5S_Def initions .Process_Instance 
( Process_Startup  =>  prSmain, 
SRO^size  =>  4:i?fe?0, 
service_perio(l  => 

t)asic_process_mana,eement .  inl'ini  te_periol_count ) ; 


—  SPECIFICATIONS  FOR  USER  PROCESS  4  — 


package  UPR0C4  is  new  ?rocess_Def initions .Process_In£iance 
( Proc8SS_Siartup  =>  pr4main, 
SRO_size  =>  4000, 
service_period  => 

Basic  Process  Manaffemeni . Infinite  Period  count); 


—  BODIES  FOR  USER  PROCESS  1  — 


procedure  prlnam  is 
begin 

U5er_Process_l.MAlN; 
end  prlmain; 


—  BODIES  FOR  USER  PROCESS  2  — 


procedure  pr2main  is 
fceein 

U5er_Process_2.main» 
end  pr2main; 
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—  £ODI£S  FOR  USER  PROCESS  3  — 


procedure  pr2main  is 

be^in 

U52r_?roces5_3.main; 
end  prSmain; 


—  BODIES  FOR  USER  PROCESS  4  — 


procedure  pr^.nain   is 
be^in 

User_Process_4:.main; 
end   pr4:main; 


—  PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES  — 

procedure  Initialize 

is 
Deein 

UPROCl.Conpiete_process_iniiiaiizatioa; 

UPR0C2.Complete_process_initiaiization; 

UPROC3.Co'npl9te_process_initialization; 
—     UPROC4:.CorTipiete_proces5_iniiiaiization» 
end    Initialize; 

end  User  Processes; 
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iNFPSERPi^MBS 

Pragma   environinent(  "ACS  :  BPM.  MLE" /'ACS  :71USRP  .MLl"  » 

"PRlMAlN.N'SE"/'PR2MAlN.MSE","PR3r^AlN.MSE","PR4^AlN.MS  P"  ); 
with  Process_Def ini tlons,  i^AX_Def ini tions , 

Basic   Process_rrana?er!eni  »* 
with  Qser_Proce5S_l ,User_Process_2 ,U5er_?rocess_3  , 

Usir_Proce55_4; 
pacfcaee    Gody  User_Processes    is 

—  Function: 

—  This  module   instantiates   tne  user  processes   and 
~   provides  an  initialize  procedure  which  completes  the 

—  initialization  of  eacn  user  process. 

—  For   each  user  process,   there  is  an  instance   of 

—  iMAX_Definitions.procedure_vai  which   contains   the 

—  process'  initial  procedure.   To  minimize  the  size  of 

—  this  pacKasre,  the  initial  procedure  nere  simply  calls 

—  the   actual   initial   procedure  which   is   found   in 

—  another  module.    For  each  process,   there  is  also  an 

—  instantiation  of  Frocess_Def ini tions .Process_In5tance 

—  which  specifies   the  process  id,   the   procedure_val 

—  just  mentioned,  and  the  process'  staclc  SRO  and  object 

—  table  sizes. 

—  Finally,   the   initialize  procedure  provided  by   tnis 

—  module  simply  calls  the 

—  Complete_process_ini tialization   procedure   in   eacn 

—  instantiation  of  Proc9SS_Def ini tions .Process_Instance 

procedure  prlmain; 
procedure  prlmain; 
procedure  pr3maln; 
procedure  prlmain; 


—  SPECIFICATIONS  FOR  QSER  PROCESS  1  — 


pacira^re  UPROCl  is  new  Process_Cef initions.Process_Instance 
(Process_S tartup  =>  prlmain, 
SRO_size  =>  400t5, 
service^perlod  => 

basic_process_management . inf inite_period_count ) ; 
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—  SPECIFICATIONS  FOR  USER  PROCESS  2    — 


package   UPR0C2   is   new   Process_Def iniilons .Process_Ins tance 
( Process_Siartup  =>  pr2main, 
SRO_slze   =>   40fe}0, 
service_period   => 

baslc_process_management .  infini  te_perio(l_count )  > 


—   SPECIFICATIONS    FOR   USER   PROCESS    3   — 


pactrage   UPR0C3   is   new  Proce5S_Def  ini  tions  .Process_Ins  tance 
( Process_Startup  =>   prSmain, 

SRO_size  =>  4000, 
service_periol  => 

basic_proce5S_:Tianagement  .inf  inite_perioa_count )  ; 


—  SPECIFICATIONS  FOR  USER  PROCESS  4  — 


package  UPR0C4  is  new  Process_Def initions .Process_In5tance 
(Process_S tartup  =>  pr4main, 
SRO_size  =>  40?0» 
service_period  => 

Basic  Process  Management . Infinite  Period  count); 


—  BODIES  FOR  USER  PROCESS  1  — 


procedure  prlmain  is 
&  e  ?  i  n 

Use r_Process_l. main; 
end   prlmain; 


—  BODIES  FOR  USER  PROCESS  2  — 


procedure  pr27iain   is 
Begin 

User_Process_2,main; 
end   pr2rnain; 
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—  BODIES  FOR  USER  PROCESS  3  — 


procedure  prSmain  is 
be^in 

0ser_Process_3.main; 
end  pr3main; 


—  BODIES  FOR  USER  PROCESS  4  — 


procedure  pr4:main  is 
begin 

User_Process_4.mainf 
end  pr4main; 


—  PROCEDURE  TO  INITIALIZE  ALL  USER  PROCESSES  — 

procedure  Initialize 

is 

bes-in 

UPROCl.Co!Tiplete_process_initiaii2ation; 

UPROC2.Comple  te_process_initiali za tion; 

UPR0C3. Complete _process_ini  tialization; 

UPR0C4. Com pi ete_process_ initialization; 
end    Initialize; 

end   User  Processes; 
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I_NLINK1^LKD 
;  instruction  test  program 

linK  ACS rminmax.eod 

ACS  :textio  .mio 
intio .nso 
schar .mso 
scnar.mbo 
prlmain.mso 
prSmain.mso 

prSmain.mso 
pr4main.mso 
prl[rain.mbo 
pr2main.mbo 
prSmain.mbo 
pr4fnain.mbo 
inf pserpl .mbo 
psors .mbo 

free(30  in  directory) 

output  infcnarl.eod 

objectmap 


INFLINKE^LO 

I  instruction  test  program 

linfc  ACS tminmax.eod 
ACS  rtextio.mlo 
intio  .mso 
sctiar  ,mso 

scnar.mbo 

prlmain .mso 

pr2main.mso 

prSmain.mso 

pr-imain.mso 

prlmain. mbo 

pr2main.mbo 

pr3main.mbo 

pr4main.mbo 

inf pserp2.mbo 

psors .mbo 

free(30  in  directory) 

output  infchar2.eod 

objectmap 
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INFLINES^LKD 

;  instruction  test  program 

linu:  ACS  tminmax.eod 

ACS  rtextio.Tilo 

intio.mso 

scnar  .mso 

sc&ar.mbo 

prlmain.mso 

prSmaln.mso 

prSmain.mso 
pr4main.mso 
prlmaln.mbo 
pr2main.mbo 
prSmain.mbo 
pr4main.mbo 
inf pserp3.mbo 
psors ,mbo 

free(30  in  directory) 

output    infcharS.eod 

objectmap 


INPLINKS^LKD 

;  instruction  test  program 

linic   ACS  tminmax.eod 

ACS :teitio.mlo 

intio .mso 

scnar  .mso 

scbar .mbo 

prlfrain.mso 

pr2main.mso 

prSmain.mso 

pr4main.mso 

prlmain.moo 

pr2main.mbo 

pr3main.mbo 

pr4(T'ain.mbo 

inf pserp4.mbo 

psors .mbo 

free(30  in  directory) 

output  infcnar4.eod 

objectmap 
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JCHARl^COM 

$ada4:32new 

$ida  ACS :lntio  .mss 

Sida  scnar.mss 

$ida  schar.mbs 

$ida  trovers. common] prlmain.mss 

$ida  [rovers .comnonj pr2main.mss 
$ida  [rogers.commonJpr3main.mss 
$ida  [roffers .common] primain.mss 
$  purge 

$ida  prlmain.mbs 

$ida  prSmain.mbs 

$ida  prSmain.mbs 

$ida  pr4main.,T  t)s 

Spurse 

$ida    [rogers .commonj dfpserpl  .mDs 

$ida    [rogers.commonJdfpserp2.mbs 

$ida    [rovers .common] dfpserpS .mbs 

$ida    [rogers. common] dfp5erp4.mbs 

$purge 

$ida  [rovers. common] infpserpl .mbs 

$ida  [rogers. common] inf pserpZ.mbs 

$ida  frogers. common] infpserp3.mbs 

$ida  [rogers .common] inf pserp4.mbs 

$ida  [roffers .common] psors .mbs 

Spurge 

$linfc432    [rogers  .  common]  If  lintel 

$linl£432    [rovers. common]dflinic2 

$linic432    [rogers.  common]  df  iinis:3 

$llnk432    [rogers. common] dflin^4 

$llnS432    [rovers . common] inf linKl 

$linK432    [rogers.  common]  inf  iinic2 

$linir432    [rogers  .  common]  inf  iin^3 

$linK432    [roffers.  common]  inf  linic4 

$purge 

$delete  ==».='"''c;* 
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